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Q ■ Abstract: The new matrix element generator AMEGIC++ is introduced, dedicated to 

^ ■ describe multi-particle production in high energy particle collisions. It automatically 

generates helicity amplitudes for the processes under consideration and constructs 
suitable, efficient integration channels for the multi-channel phase space integration. 
^ . The corresponding expressions for the amplitudes and the integrators are stored in 

library files to be linked to the main program. 
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Program Summary 



Title of the program : AMEGIC++ 

Program obtainable from : authors upon request 

Licensing provisions : none 

Operating systems under which the program has been tested : UNIX, LINUX, VMS 
Programming language : C++ 
Separate documentation available : no 
Nature of the physical problem: 

The theoretical description of multi particle production, even at the tree-level, suffers 
from two problems : 

1. The rapidly increasing number of amplitudes forbids the traditional method 
of summing and squaring individual Feynman amplitudes by means of the 
completeness relations for spinors and polarization vectors. Instead, the helicity 
method is employed, translating the amplitudes into complex numbers. Still, 
the helicity amplitudes for a large number of diagrams have to be constructed 
which itself is a formidable task. 

2. The complex structure of the high-dimensional phase space imperatively re- 
quires using Monte Carlo methods for its evaluation. Here, efficiency is of 
paramount importance, and one has to employ non-flat phase space measures 
which must be optimized for the process under consideration and its specific 
singularity structure in phase space. 

Method of solution: 

Automatic generation of helicity amplitudes related to Feynman diagrams describing 
the process at the tree-level. Translating of the amplitudes into character strings 
and storing in libraries for increased efficiency during evaluation, i.e. phase space 
integration. Integration by means of multichannel methods with specific channels 
which are constructed from the Feynman diagrams. 
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1. Introduction 

In the last decades, the observation of the production and subsequent decay of par- 
ticles with rising masses [1] has lead to more and more far reaching qualitative and 
increasingly accurate quantitative knowledge about physics on subnuclear scales. As 
a consequence of this experimental success, the Standard Model [2] nowadays is 
widely accepted as the best model for the scales under current consideration. How- 
ever, many particle physicists believe that the Standard Model is only the effective 
realization of a theory valid up to much higher scales with even higher energetic par- 
ticles participating. Consequently, for the experimental verification or falsification 
of such ideas, colliders with even higher energy release are currently being planned 
or constructed [3]. Prom a theoretical point of view the increasing energy release 
does not only allow the creation of these presumably unstable new particles, in fact, 
with rising energies the number of particles or jets produced increases drastically as 
well. Therefore, to analyse both the signal and the background related to processes, 
where new heavy particles are produced and decay into high energetic secondaries, 
the description of multi-particle states is mandatory. 

However, such a description, even in the lowest accessible perturbative approx- 
imation is far from being trivial. Basically, two major problems emerge with an 
increasing number of final state particles : 

1. The number of amplitudes related to a process with n outgoing particles rises 
approximately like a factorial in n. Thus, the traditional method of summing 
and squaring the amplitudes by use of the completeness relations leads to an 
exploding number of terms to be evaluated. 

2. The phase space populated by the final state particles is multidimensional, 
enforcing the use of Monte Carlo methods for the integration. However, non- 
trivial experimental cuts on the phase space in connection with possibly wildly 
fluctuating integrands due to nearly on-shell intermediate particles make so- 
phisticated mapping and sampling methods indispensable. 

These two problems necessitate the usage of computer programs. Examples are 
CompHep [4], FeynArts/FeynCalc [5], Grace [6], MADGRAPH [7], and O'Mega/WHIZARD 
[8]. 

The new program AMEGIC++ which will be presented in this publication, proposes a 
solution to both problems discussed above. In its present form, AMEGIC++ automati- 
cally creates all Feynman diagrams related to user defined processes in the framework 
of the Standard Model. It should be emphasized here that a generahzation to a large 
variety of other models is straightforward and currently in preparation. However, the 
diagrams are then transformed into helicity amplitudes, yielding complex numbers 
for every combination of external momenta. These amplitudes, corresponding to a 
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specific process, are translated into character strings and stored in a library. For 
the phase space integration, the structure of the individual Feynman diagrams is 
analysed and suitable integration channels are generated. Again, they are translated 
into a library file. In this sense, AMEGIC++ is a program to generate highly efficient 
matrix element generators for a large variety of processes. Of course, this allows 
for an easy implementation into Monte Carlo event generators like APACIC++ (for a 
detailed description see [9]) which has been performed successfully. 

The outline of this paper is as follows: First, the theoretical background for 
both the evaluation of amplitudes and the efficient Monte Carlo generation of phase 
space points is reviewed, see Sec. 2. Special emphasis is given to the hclicity method. 
Sec. 2.1, and on some of the features of this method as implemented within AMEGIC++. 
Additionally, the multi-channel algorithm for an efficient integration is discussed in 
some detail and both default channels available in AMEGIC++ and building blocks for 
process dependent channels are hsted. At the end, some higher order effects will be 
discussed in Sec. 2.3. 

Then, large parts of the algorithms involved are discussed, see Sec. 3. They can 
roughly be divided into three parts, namely into methods for the generation of dia- 
grams presented in Sec. 3.1, for their translation into helicity amplitudes, cf. Sec. 3.2, 
and finally, into algorithms for the construction of suitable integration channels, see 
Sec. 3.3. 

In Sec. 4 the corresponding classes are hsted and their interplay is described. 
This description is roughly split into the following parts: 

• First, Sec. 4.1 deals with the overhead, i.e. classes to drive AMEGIC++. 

• Then, in Sec. 4.2, the general set-up of models is discussed. 

• Sec. 4.3 describes the classes responsible for the construction of Feynman dia- 
grams, their translation into helicity amplitudes and their calculation. 

• In Sec. 4.4 the essential methods for the translation of the hclicity amplitudes 
into character strings and their storage in corresponding library files will be 
highlighted. 

• Sec. 4.5 explains the construction of the phase space integrators, the channels, 
and how they are used during the integration. 

• In Sec. 4.6, the parameters and switches to be set by the user are explained 
and how they are read in. 

• Finally, in Sec. 4.7 some more general helper classes are listed. 

At the end an installation guide is given in Sec. 5 and a summary. Sec. 6 concludes 
this paper. Note that a Test Run Output can be found in Appendix D as well. 
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2. Theoretical background 



Before we present the algorithms and their implementation in AMEGIC++ in some 
detail, we will give a brief review of the underlying calculational methods. More 
specifically, in Sec. 2.1 we will dwell on the method of helicity amplitudes as in- 
troduced in [10, 11] and clarify our notation. Then, in Sec. 2.2, we will review the 
multi-channel methods [12] employed for the subsequent phase space integration of 
the matrix element. 

2.1 Helicity amplitudes 

The basic idea behind the method of helicity amplitudes is that for every combina- 
tion of helicities and momenta for the incoming and outgoing particles any Feynman 
amplitude (represented by propagators and vertices for the internal lines and spinors 
and polarization vectors for the external particles) is nothing else but a complex 
number. Once every such number is computed, all amplitudes for a process under 
consideration can be easily summed and the result can then be squared. Inclusion 
of colour factors etc. is straightforward and reduces in this framework to the multi- 
plication of two vectors of complex numbers (for the amplitudes and their complex 
conjugated) with a colour matrix in the middle. The question to be answered in this 
section is how we can extract the numerical value of the amplitudes as a function of 
the external momenta and helicities. In AMEGIC++, we follow quite an old approach 
to answer this question which has been proven to be adequate and successful in a 
large number of specific processes [11] ^. This approach relies on decomposition of 
the amplitude into scalar products of four-momenta and into spinor products of the 
form u{pi, Xi)u{pj, Xj), where the pij and Xij are momenta and helicities, respec- 
tively. Knowing the four-momenta, the scalar products can be calculated easily, and 
for fixed helicities, the spinor products can be computed as well. As we will see, 
the result for such a spinor product is a function of the components of the momenta 
involved. This allows for the translation of any Feynman amplitude into generic 
building blocks which can be evaluated numerically. In the following we will give a 
short introduction into the spinor techniques we use for this decomposition and we 
will hst the building blocks employed in AMEGIC++. 

2.1.1 Spinors 

As it is well known, appropriate spinors u(p, A) for fermions with mass m, momentum 

^However, we want to point out that other approaches exist [13] which are based on the LSZ 
theorem and allow the direct recursive construction of matrix elements without taking the detour 
of Feynman amplitudes. These approaches are currently under further investigation and discussion. 
Nevertheless, we are convinced that in the light of the need for efficient mappings of the phase space 
to specific channels reproducing the singularity structure of the process under consideration, the 
construction of Feynman amplitudes is still a sine qua non. 
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p and with definite helicity A obey Dirac's equation of motion (E.o.M.) 

- m)u{p, X) ^ , {^ + m)v{p,X)^0. (2.1) 

Note tliat since ^ is not necessarily liermitian, m does not need to be real, but in any 
case p^ = w? is fulfilled. With p^ < 0, m turns imaginary and one can identify the 
particle spinor with the positive imaginary eigenvalue m (Im(m) > 0). Additionally, 
the spinors should fulfill 

(1T7VMp,±) = 0, (1T7V>(p,±) = (2.2) 

with the polarization vector s obeying s ■ p — and = 1. 

To construct spinors satisfying both Eqs. (2.1) and (2.2), even for imaginary 
masses, we start with massless chiral spinors w, i.e. spinors satisfying 

w{ko, X)w{ko, A) ^ ^ ^2^'' h > (2-3) 

for arbitrary light-like Uq. Starting from such a chiral spinor u'(/co. A) with definite 
chirality, spinors of opposite chirality w{kQ, —A) can be constructed via 

w{koA)^HMko,-X) (2.4) 

with the vectors A;o,i satisfying ^ 

kl^Q , ko-ki = Q, kj^-l. (2.5) 

Massive spinors can then be expressed as 

u(p, A) = w{ko, -A) , v(p, A) = w(ko, -A) (2.6) 

V 2p ■ ko V2p ■ ko 

in terms of these chiral spinors. These relations hold also true for p^ < and 
imaginary m. For the construction of conjugate spinors we will abandon the proper 
definition 

fZ = -uV, v^v^-f^, (2.7) 
since this definition does not lead to the E.o.M. 

u{p, X){^ - m) ^ , v{p,X){^ + m)^0 (2.8) 
for spinors with imaginary masses. Instead we use Eqs. (2.8) and 

u{p,±){lT^' ^)^0, ^;(p,±)(1:F7'^) = (2.9) 

^Note that we have some freedom in choosing the fc- vectors which provides a valuable tool for 
checking the calculation. 
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to define conjugate spinors. With this definition, and choosing the normahzation 

u{p, X)u{p, A) = 2m , v{p, X)v{p, A) = -2m , (2.10) 
the conjugate spinors are constructed as 

A) = Mh. -A) ^ , .(p, A) = MM, -A) ^ . (2.11) 

They fulfill the completeness relation 

^ ^ ujP, >'Mp, A) - vjp, X)vip, A) 

A 2m ■ ^ ■ ^ 

The last relation can now be used to decompose the numerators of fermion propaga- 
tors according to 



U{P1: Ai) Xl + /^2) X3 U{P3: A3) 



1 



J2 U{P1, Ai) Xl m(P2, A2) ii(p2, A2) X3 m(P3, A3) ( 1 + 



A2 



^2 
1712 



Ai)Xl^^(P2, A2) V(p2, A2)X3m(P3, A3) ( 1 - — 

V m2 

where ml = p| and the x denote the (scalar or vector) couplings involved. 



(2.13) 



2.1.2 Polcirization vectors 

1. Massless bosons : 

The next task on our list is to translate the polarization vectors e{p, A) of 
massless external spin-1 bosons with momentum p and hclicity A into suitable 
spinor products. Massive bosons will experience a different treatment, we will 
deal with them later. However, for massless bosons, the polarization vectors 
satisfy 

e(p, A) ■ p = , €{p, A) • €{p, A) = , 

ei^ip, -A) = e'^*{p, A) , e(p. A) • e{p, -A) = -1 . ^ ' ' 

In the axial gauge the polarization sum reads 

E e^(p, A)e-(p, A) = -g'^'' + ^'^'^ + , (2.15) 

where is some arbitrary, light-like four vector not parallel to p^. It can be 
shown that the spinor objects 

«(g,A)7'^«(p,A) (2.16) 
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satisfy the properties of Eqs. (2.14) and (2.15) and hence form an acceptable 
choice for the polarization vectors of massless external spin-1 bosons. From 
this identification, we obtain an additional constraint for q^, namely that it 
should not be coUinear to k^. Note, however, that the freedom in choosing q 
reflects the freedom in choosing a gauge vector in the axial gauge. Since flnal 
results should not depend on such a choice, we have another tool at hand to 
check our calculations. 



2. Massive bosons: 

For massive bosons, the situation changes. First of all, there is another, longi- 
tudinal polarization state which satisfies the same properties as the transversal 
states, Eq. (2.14). In contrast to the massless case, however, the spin sum 
changes and becomes 

Y: e^^ip, A)e-(p, A) = -g^^" + ^ , (2.17) 

where m is the mass of the boson. We introduce 

a" = u{r2, -h^uin, -) (2.18) 

with light-like four vectors ri and r2 satisfying 

rl = rl = and r'^ + = p>' . (2.19) 

Replacing the spin sum by an integration over the solid angle of ri in the rest 
frame of p, we obtain 

(2.20) 

47r 



which is of the desired form. Therefore, identifying 

3 

A=±,o -'^"■^ 4 
we will arrive at the correct form for the unpolarized cross section. 



In other words, the polarization vector of a massive vector boson can be con- 
structed in terms of spinors via a pseudo-decay of the boson into two massless 
fermions with coupling constant 1. 
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2.1.3 Building blocks 

Finally, we will present the basic spinor products which serve as elementary building 
blocks for our amplitudes. We introduce the following short-hand notations : 

• projectors 

Pl,r = ^ ; (2.22) 

• S'-functions 

c,/ , N o ^0 ■ P^^^ ■P2-ko- P2ki ■ pi + ief,upak^k'(p^p^ 

^{+',Pi,P2) = 2cl (2.23) 

Vim 

with the symmetry properties 

S{-,Pi,P2) = S*{+-p2,p,) and S{±-p,,p2) = -S{±-p2,Pi) ; (2.24) 

• normalizations and mass-terms 

r]i = J2pi- ko and /li = ±— , (2.25) 
^ Vi 

where the signs denote particles and anti-particles. 

The following spinor expressions are then the basic building blocks for helicity 
amphtudes within AMEGIC++ : 

1. Y{pi, Ai;p2, A2; cl, cr) = tZ(pi, Xi)[clPl + crPr\u{p2, X2) ; 

2. X{pi, Ai;p2;P3, A3; Cl, cr) = u{pi, Ai)^[cl-Pl + CRPi^uip^, A3) ; 

3. Z{pi,\i;p2,\2;PzA?,;PiAi,C^L,C^R,cf,C^R) = 

m(Pi, XimCLPL + c'iPRHp2, X2MP3, A3)7m[Cl + C^rPrHp^, A4) • 

Their explicit form can be found in Tabs. 1,2, and 3. However, let us note that, in 



A1A2 


y{Pi,Xi;p2,X2;cL,CR) 


A1A2 


y{Pl,XuP2,X2;CL,CR) 


++ 


Ci?A*i772 + clIJ^^Vi 


+- 


clS(+;pi,P2) 



Table 1: ^-functions for different helicity combinations (Ai, A2). The remaining Y- 
functions can be obtained by exchanging L ^ R and + -(-^ — . 
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AiAs 


X{pi,\i;p2;p3,h;cL,CR) 


++ 
+- 


ifJ'im + fJ'2Vl) {fJ'2mCR + fJ'3V2CL) + CrS{ + ;Pi,P2)S{-;P2,P3) 

cl {fJ'iV2 + fJ'2Vi) S{+;p2,P3) + {cLfi2V3 + CR^J'3V2) S{+;pi,p2) 



Table 2: X-functions for different hclicity combinations (Ai, A3). The remaining X— 
functions can be obtained by exchanging L R and + <->—. 



A1A2A3A4 


Z{pi, Xi;p2, A2;P3, A3; P4, K; , cj|; cf, 4^) 


+ + ++ 


2 [S{ + ;P3,Pi)S{-;P2,P4)CrC^r + /il/i2^3^4CP4 + ^^3^^^VlV2CRcf] 


+ + +- 


2ri2cj^ [S{+;pi,p4)iJ,3cf + S{+;pi,p3)iJ,icj^] 


+ + -+ 


'^ViCr [S{-;P3,P2)f^4cfq + S{-;p4,P2)f^3CR] 


+ + — 


2 [S{ + ;P4,Pl)S{-;p2,P3)CRcf + ^l^2mViCfcf + /X3/^4??l ^24^41 


+ - ++ 


27^44 ['5(+;Pl,P3)/X24' + '5(+;P2,P3))UlcF] 


+ - +- 





H h 


-2 [//1//4772?73CF4'^ + IJ'2lJ'3'nm(^R(^R " fJ'ifJ'Smmcfcf - H2lJ'4r]l'n3CRcf] 


H 


'^mcf [^(+;P4,P2)//icF + ^(+;pi,P4)Ai24'] 



Table 3: Z-functions for different hehcity combinations (Ai, A2, A3, A4). The remaining 
Z-functions can be obtained by exchanging L ^ R and + -(-^ — . 



general, products like 

u{pihMP2MP3hMP4) ■ (^'^^ - (2-26) 

(stemming from the exchange of a massive boson with mass M and momentum P 
between the two fermion lines) cannot be represented in terms of one elementary 
Z-function per helicity combination. Instead, some composite functions, consisting 
of Z- and X-f unctions, become necessary. 

Similarly, the propagation of longitudinal modes in off-shell vector bosons pre- 
vents us from employing polarization vectors to replace the numerators of the prop- 
agators. Therefore, structures with three or more bosons can not be "cut open" 
and suitable building blocks need to be constructed for any such structure. Within 
AMEGIC++, building blocks for the structures depicted in Figs. 1, 2, and 3 are available 
at the moment, somewhat limiting the maximal number of vector boson lines. Note 
that since vertices involving only scalar bosons are proportional to scalars, there is 
no need to define specific three or four scalar vertices. Similarly, scalar propagators 
can easily be cut open and even more complicated structures can be decomposed into 
easier ones as depicted in Fig. 4. Here, we feel, a further clarification is in order. As 
the observant reader might have noticed, we omitted vertices with four vector bosons 
in our pictorial presentation of the building blocks. Instead, we chose to disentan- 
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Figure 1: Three boson vertices available within AMEGIC++. Note that all boson lines 
might be on- or ofF-shell. Scalar and vector bosons are depicted as dotted and wavy lines, 
respectively, whereas a gluon is marked by a curly line. 

gle the gauge structure of such vertices and map them piecewise on corresponding 
sequences of two three-boson vertices as depicted in the upper left diagram of Fig. 2. 

2.2 Phase space integration 

Now we are in the position to discuss the issue of integrating the amplitudes. Due 
to the high dimensionality of the phase space (3n — 4 for n outgoing particles) and 
because of possible non-trivial cuts on the phase space reflecting the experimental 
situation, we have to abandon the idea of exact analytical integration. Instead we will 
employ Monte Carlo methods, i.e. we will sample the matrix element, here denoted 
with f{x), over the allowed phase space. Its points x are then distributed randomly 
according to the probability distribution g{x). Defining the weight 




m 



(2.27) 



we can transform the true integral into a Monte Carlo estimate E{f) via 




(2.28) 
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/ 



/ 



Figure 2: Four boson vertices available within AMEGIC++. Note that all boson lines might 
be on- or off-shell. Scalar and vector bosons are depicted as dotted and wavy lines, 
respectively, whereas a gluon is marked by a curly line. 




Figure 3: Five gluon vertex available within AMEGIC++. Note that all boson lines might 
be on- or off-shell. 



To estimate the error of this estimate E{f), we need the square root of the variance 
V{f) given by 



V{9) 



1 r 



( 



1 



W{g) - E'if) 



(2.29) 



N 



N 



13 




Figure 4: Scalar propagators can be cut easily. Scalar and vector bosons are depicted as 
dotted and wavy lines, respectively. 

where we have identified 

W{g) = {w\x))^ . (2.30) 

The name of the game is now to find a g that efficiently minimizes V{f). This 
might become quite a tricky business, since usually, the amplitude squared f{x) is 
wildly fluctuating due to resonant structures in propagators and - in the Monte Carlo 
sense - singular behavior at some edges of the allowed phase space. As illustrative 
examples, consider the phase space for the processes 

e+e- ^ W+W- Af and e+e" ^ qqg (2.31) 

which suffer from the resonant VT-propagators or from the soft and coUinear diver- 
gencies related to the gluon emission, respectively. To solve this problem of mapping 
the phase space efficiently to suitable probabihty distributions, AMEGIC++ employs 
the multi-channel method described for instance in [12]. The cornerstone of this 
method is the knowledge about the singularity structure of individual processes and 
the possibility of constructing an efficient mapping as a sum of specific channels. 
Each of these channels is constructed to cover the full phase space under consider- 
ation with special emphasis, i.e. higher probability density, on one of the singular 
regions. In the following we will briefly review this method and list the ready-to-use 
standard channels in AMEGIC++ plus the building blocks for the constructed channels 

3 

2.2.1 Multi channel method 

As indicated above, the basic idea of the multi-channel method is to introduce dif- 
ferent mappings of the phase space, i.e. different distributions of the x. Each of 
these channels gi{x) with i = 1, ... ,n is nonnegative over the full phase space and 
normalized to unity, 

J dxgi(x) = 1 . (2.32) 

^The building blocks used in AMEGIC++ were used already in [14]. Note that similar approaches 
were discussed in the literature, for example see [15] and [16]. 
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The various gi contribute according to so-called a priori weights > which again 
are normalized to unity, i.e. 

n 

E«* = l- (2-33) 

i=l 

Thus, the multi-channel mapping g is 

g{x)=J2(^i9iiS)- (2.34) 

i=l 

Since in Eq. (2.29) E{f) — {w{x)) is independent of g{x), we see immediately that 
we need to minimize {w{xY)g with respect to the ctj in order to minimize our error 
estimate. It is well known that the overall variance is minimized by distributing it 
evenly over the channels used. In practice, the essential part of the variance per 
channel can be easily estimated during the sampling procedure via 




(2.35) 



Obviously, ctj should increase, i.e. the channel i should contribute more, if its variance 
is large, i.e. if Wi is large. In other words, the more wildly fluctuating a channel is, 
the more Monte-Carlo points using this channel should be produced to smooth out 
the fluctuations of this particular channel and hence of the overall result. This leads 
to an iterative improvement of the ctj with help of the W^. 

In AMEGIC++, we therefore iterate an optimization procedure of the ccj with a 
limited, uscr-dcfincd number of steps. In each optimization step, i.e. after a pre- 
determined (and again user-defined) number of Monte-Carlo points, the a priori 
weights are reshuffled according to 

^new ^ ^old^, ^^oldy _ ^2.36) 

Again, they are normalized in order to cope with the constraint that they add up to 
unity. Note that /3 should obey < /3 < 1. In AMEGIC++ its default value is 1/2. The 
optimal set of weights yielding the smallest overall variance during this procedure 
is stored and used afterwards, i.e. in the full evaluation of the cross section. Note, 
however, that the results accumulated during the optimization procedure are added 
to the final estimate. 

In the following sections we are going to introduce the channels available within 
AMEGIC++. They can be roughly divided into two sets, one set of default channels, 
where the only process dependence manifests itself in the number of momenta pro- 
duced, the other set consisting of the channels which are constructed by exploring 
the phase space structure of specific diagrams. 
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2.2.2 Default channels : RAMBO and SARGE 

We will start with a brief description of the default channels within AMEGIC++, namely 
RAMBO and SARGE. For a more detailed discussion of these two integrators we refer to 
the concise and clear original publications [17, 18]. 

1. RAMBO: 

Essentially, RAMBO produces any number n of uniformly distributed massless 
or massive momenta in their center-of-mass frame, i.e. a flat n-particle phase 
space. Massless momenta are generated in two major steps : 

(a) Energies and solid angles for n "unrestricted" momenta are produced inde- 
pendently, with a flat distribution of the angles in cos^, the polar angle, 
and 0, the azimuthal angle. The energies Ei are chosen according to 
-Ejexp(— with no constraints whatsoever. 

(b) The n "unrestricted" momenta are rescaled in order to obey the conserva- 
tion of total four-momentum. This changes both the energies and angles 
of the unrestricted momenta when they are mapped to the "restricted" 
momenta. 

For massive momenta another step is now added 

(a) The massless momenta are rescaled once more, in order to bring them onto 
their mass-shell. In addition, this induces an extra non-trivial weight (i.e. 
depending on the actual set of vectors) , compensating for the rescaling of 
the momenta. 

3. SARGE: 

In contrast, SARGE generates n massless momenta distributed according to the 
antenna pole structure 

^ (2.37) 



{PlV2)ij>2Vz) ■ ■ ■ {Pn-lPn){PnPl) ' 

In principle, the momenta are produced again in two major steps : 

(a) Two massless momenta qi and g„ are produced in the cm. frame of 
the process. Starting from these two momenta the others are produced 
recursively via "basic antennae" dA^j according to dAf^^dA^ ,^ . . . dA^z\n- 
In the expression for the individual dAfj, the lower indices i and j de- 
note the two initial momenta and k denotes the generated momentum, 
respectively. The antennae density is given as 
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with 

9(0 = WT-^^i^ - UnMC - ^min) ■ (2.39) 

It should be noted that ^min can be related to some physical cuts in relative 
angles of the momenta and transverse momenta. 

The algorithm then is to generate and cos 6 (the angle between k and 
one of the two initial momenta) in the cm. frame of the initial momenta 
according to dA, distribute the polar angle uniformly and boost the three- 
momentum system back to the frame where the initial momenta were 
given. Obviously, this procedure does not satisfy overall four-momentum 
conservation, thus the next step is mandatory: 

(b) The n "unrestricted" momenta qi are boosted and rescaled in order to obey 
the conservation of total four-momentum. Again, this changes both the 
energies and angles of the unrestricted momenta when they are mapped 
on the "restricted" momenta, but, of course, it leaves the scalar products 
related to the single antennae invariant. 

Let us note in passing that the algorithm outlined above constitutes only the 
basic version of SARGE, improvements outlined by the authors of this algorithm 
have been implemented into AMEGIC++. 

2.2.3 Building blocks for additional channels 

In addition to the two default channels presented in Sec. 2.2.2, AMEGIC++ analyses 
the phase space structure related to the process and constructs automatically one 
channel corresponding to every individual Feynman diagram. In Tab. 4 we give some 
insight into the building blocks, propagators and decays, of these channels. 

2.3 Higher-order effects 

Some higher-order effects have been included in AMEGIC++ in order to increase the 
precision of some of the processes to be calculated. The first example is the consid- 
eration of Coulomb effects for two charged bosons which have been produced near 
their mass-shell, Sec. 2.3.1. On the other hand higher-order effects can be included 
via the running widths of particles, see Sec. 2.3.2. 

2.3.1 Coulomb corrections 

In principle. Coulomb corrections contribute to all processes with electrically charged 
particles. They are particularly important, if two particles are created close to each 
other and move with a low relative speed. Then the long-range interactions alter the 
corresponding cross section by a possibly sizeable factor ~ l/i> with v the relative 
velocity. 
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1. Propagators : 



Propagator 


Distribution 


Weight 


massless 


simple pole l/s^ with exponent 77 < 1 


s"^ — s' ■ 

max "mm 




massive 


Breit-Wigner with mass M, width F 


1 MP 


TT (S - M2)2 + M2P2 



2. Decays : 



Decay 


Distribution P — > 


Weight 


isotropic 2~body 


flat, Pi have masses 


2P2 

7r^X{P',plpl) 


t-channel 


/7t -I- fin ^ —1— Tin Til TTli^Q- 

sivc, 

cos^^ between qi and pi 
is distributed like l/(a — 
cos Oy in the rest frame 
(a depends on mass of the 
propagator) . 




anisotropic 2-body 


cos^ between P and pi in 
the rest frame of P is dis- 
tributed like 1/cos''^, pi,2 
are massive 


1P2 1 

1-77 

(COS^-" 6'inax " COS^"" 6'inin) 


isotropic 3-body 


flat, only p2 is massive 


4 



Table 4: Various decays and propagators used within AMEGIC++ for the creation of addi- 
tional channels. Here, A(s, si, S2) = (s — si — s2)^ — 4siS2 • 



Within AMEGIC++, such corrections are included for the production of W^-bosons 
as in [19] with a factor 



'^coul 



with 



2(3 



l-^arctan'(^-;/)' 
71 2i3lm{i3M) 



(2.40) 



P. 



'M 



s - 4M^ + AiFwMw 
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Ml -Ml 

A = ^ 

s 

P ^ I . J[s - (M+ - M_)2] [s - (M+ + M_)2] . (2.41) 
s * 

This factor just multiplies the corresponding amphtudes with a VF'^l^^-pair for 
the higher-order correction, i.e. effectively a one plus this factor is multiplied. The 
amplitudes including the photon are depicted in Fig. 5, where we have neglected the 
decay of the 1^-pair. 




Figure 5: Diagrams related to the Coulomb correction as implemented within AMEGIC++. 



2.3.2 Running masses and widths 

Possible schemes for the running of quark masses and boson masses and widths, 
respectively, have been implemented in AMEGIC++. First of all, the LO running quark 
masses are related to the pole mass mpoi = m{m) via the well-known formula: 



im 



m{m) 
6Cf. 



as{m) 



/2/3(0) 



(2.42) 



Here, the running of the strong coupling as is used. Note that a leading order running 
for both, the strong and the electroweak coupling q;qed is implemented as well. The 
second part belongs to the running of the boson widths. Accordingly, a first ansatz 
uses fixed masses and widths, whereas the other two try some sophisticated schemes 
for the running and appropriate change of these parameters, see Tab. 5. For further 
details and a comparison between the advantages and disadvantage of these schemes 
we refer to the literature [20]. 
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Scheme 


mfl(s) 







^pole 


^ pole 


1 


2 

^pole 


^poicrpoic 




\/'^pole ~ -'^pole 


2 


'^pole 


r ^ 

^ pole 

^pole 



Table 5: Running widths and accordingly modulated masses for the electroweak gauge 
bosons within the schemes provided by AMEGIC++. 
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3. Algorithms 



In this section we describe in some detail the main algorithms implemented in 
AMEGIC++. We focus on the algorithms employed to generate Feynman diagrams, 
Sec. 3.1, to translate them into hclicity amplitudes. Sec. 3.2, and, finally, on al- 
gorithms employed for the construction of suitable channels for the phase space 
integration. Sec. 3.3. 

3.1 Generation of diagrams 

Let us start with the generation of Feynman diagrams for a given process. Basically, 
within AMEGIC++, this proceeds in four steps, namely 

1. the creation of empty topologies, 

2. setting the endpoints (incoming and outgoing particles), 

3. the determination of suitable intermediate propagators, and, finally 

4. the elimination of possibly occurring identical diagrams. 
In the following, we will discuss these steps in more detail. 

3.1.1 Creation of empty topologies 

The topologies which are created and 
then filled by AMEGIC++ during the gen- 
eration of Feynman amplitudes, consist 
of binary trees of linked knots, called 
Points. Each of these knots splits into 
two branches and - correspondingly - 
two new knots. Therefore, within each 
point there exist links to a left and 
a right point. Consequently, knots 
which are not splitting any more, point 
to empty right and left knots. Addi- 
tional information within a point con- 
sists of the flavour of the incoming line 
and some direction indicated by 6 =±1, 
depending on whether the line is taken 
as incoming or outgoing. 




right 



Let us note that within the Standard Model and its most popular extensions, 
interactions between particles are described by means of vertices with three and four 
external legs. In all interesting cases we can understand any four-vertex as two 
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iterated three-vertices with a shrunk internal hne. Therefore it is sufficient to use 
only the binary points for the construction of our topologies. 

Consider now processes with A^in incoming and A^out outgoing particles, respec- 
tively. Clearly, starting from a single initial line h, we need to construct topologies 
with A^ieg = A^in + Nout — 1 additional legs. This can be done recursively, employing 
all topologies with n < Meg- The idea here is to split the initial line k into a left and 
a right branch. The left line k then is replaced with all topologies with li ^ n legs, 
and the right line 1.^. with all topologies with Ij. — » A^icg — n legs. Graphically, this can 
be understood as depicted in Fig. 6. Within AMEGIC++ there is a clear distinction 




Figure 6: Recursive structure for the construction of topologies. 



of left and right legs due to the internal structure of physical vertices which will 
be mapped onto the blank topologies in later steps. This is why the sum in Fig. 6 
extends to A^ieg — 1 instead of only half of it. 
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3.1.2 Setting the endpoints 




The next step is to set the endpoints, 
i.e. to distribute the n = N-m + -/Vout 
incoming and outgoing particles over 
tiic external legs of the corresponding 
topologies. A crucial role plays the way 
how the vertices are set up internally, 
and how the diagrams will be mapped 
on the helicity amplitudes. In fact, this 
allows us to define a number of criteria 

the endpoints have to meet. First of all, \ "\ ^ n-2 

the first incoming particle is set on po- 
sition 1, i.e. it constitutes the "trunk" 
of the topology. All other particles are 
then permuted over positions 2 to n. 

However, the set of permutations leading to accessible Feynman diagrams is 
limited by the intrinsic ordering of incoming and outgoing lines in AMEGIC++, see 
Tab. 6. These limitations ^ are reflected by the following constraints to be applied 
to the particles on positions 2 and n : 

1. If the particle on position 1 is an incoming quark gin (lepton of the A;th gener- 
ation /j^) the particle on position n has to be either an incoming anti-quark gin 
(/^ ) or an outgoing quark ^o^t (^out) • 

2. If the particle on position 1 is an incoming anti-quark gin (anti-lepton of the 
kth generation Z^) the particle on position 2 has to be either an incoming quark 
Qont (^out) outgoing anti-quark gin {l^J . 

These two conditions reflect the fact that any incoming fermion on position 1 leads 
to another fermion (incoming or outgoing) and one boson. Looking up the ordering 
of particle types in the vertices (as specifled in Tab. 6), it is obvious that spinor lines 
stretch from the incoming particle in [0] to the outgoing particle positioned on the 
right leg in [2], whereas anti-spinor lines stretch from in[0] to in[l]. Thus, in 
addition with the following algorithms to find intermediate lines (as applied to the 
boson line attached to the fermion on position 1), the two conditions above guarantee 
that the existence of a first fermion-fermion-boson vertex is not ruled out a priori. 

For further refinement, there is some bookkeeping of incoming and outgoing 
fermions, represented by a variable gsum for the quarks and similarly for each lepton 



^Note that at the moment, Standard Model processes only are available within AMEGIC++. How- 
ever, the inclusion of some popular extensions of the Standard Model into AMEGIC++ is under way. 
For these, conserved baryon and lepton generation-number will also be assumed at the beginning. 
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generation. After each position of the external legs is equipped with a particle, 
is calculated for each permutation according to 




Qsnm + 1 , if particle = or ^out 
Qsum - 1 , if particle = gout or 



Permutations under consideration are thrown away, if 

1- Qsum ever exceeds when a quark sits on position 1, and position n is occupied 
by either an incoming anti-quark or an outgoing quark, or if 

2. gsum ever drops below 0, if an anti-quark sits on position 1 and position 2 is 
occupied by either an incoming quark or an outgoing anti-quark. 

The same conditions apply generationwise for the leptons. Whenever a permuta- 
tion of the external particles meets the requirements outlined above, the endpoints 
are set accordingly, i.e. they are supplied with the position numbers of the specific 
permutation under consideration. 

Intermediate points receive increasing numbers larger than 99 to distinguish them 
from endpoints later on. This procedure of giving numbers to the individual points 
is realized recursively, using the following steps: 

1. Start from point 1. Set as its number the number of the first particle. 

2. Go to the left point. If it is an endpoint (i.e. with empty left and right links), 

set the next position of the permutation sequence as its number and proceed 
to 3. If it is not an endpoint, supply it with an internal number and increment 
the corresponding counter. Repeat this step. 

3. Go back one step and then to the right point. Again, if it is an endpoint, 
set the corresponding number of the permutation, and repeat step 3. In the 
complementary case, supply it with an internal number and go to step 2. If 
there is no right point left, the topology is equipped with all endpoints set. 

Note that in this procedure, the position numbers of the permutation arc synonymous 
for the corresponding particle which consists at this stage of a flavour and the flag 
b = ±1, where the two signs depend on whether the particle is outgoing or incoming. 

To keep track of additional minus signs due to the exchange of two identical 
fermions, the original numbers of the particles are compared with their permuted 
numbers. Whenever the ordering of the original and the permuted numbers of two 
identical fermions does not coincide, the overall sign of the specific combination of 
endpoints is multiplied by —1. 
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3.1.3 Finding intermediate lines 

Having at hand such a topology with cndpoints set and internal numbers for the 
propagators, the aim is now to find suitable intermediate lines connecting the external 
points of this specific topology. If any set of intermediate lines is found, a Feynman 
diagram has been successfully constructed, and if not, the topology can be neglected. 
Again, the determination of the internal lines proceeds recursively along the following 
steps: 

1. Start from point P with a given flavour. Check whether either the left or the 
right or both links are not yet equipped with a flavour. If this is the case, test 
all available vertices for a flt to the known flavours of P and its links. For every 
fit copy the topology with this new vertex set. If both flavours were already 
set, go to the next point and start again. 

2. If the left link was not yet equipped with a flavour, repeat step 1 with P Pieft. 

3. If the right link was not yet equipped with a flavour, repeat step 1 with P — > 
p 

right ■ 

We will now discuss in some detail, how vertices are tested for a fit into the topol- 
ogy. For this it is indispensable to explain briefiy, how vertices are defined within 
AMEGIC++. For simplicity we will display only vertices for two fermions and one 
boson, fi — > plus their "barred" combinations. Note, however that the same 
transformations apply also for bosons. 

Basically, within AMEGIC++ there are six different ways to group these three 
flavours as incoming or outgoing lines, possible double countings due to identical 
flavours will be eliminated during the initialization of the vertices. In general, during 
the matching of the vertices onto the topologies, positions in[0] , in[l] , and in [2] 
will be mapped onto a point, its left, and its right link, respectively. As can be seen 
in Tab. 6, the fermions are ordered in a speciflc way, namely the outgoing fermions 
on position in [2] and outgoing anti-fermions on position in[l]. 

The test of the vertices for a flt into a given topology now proceeds on three 
levels: 

1. The flavours and &-flags of the point under consideration are determined. For 
simplicity, let us introduce f 1 [0] , f 1 [1] , and f 1 [2] and similarly b [0] , b [1] , 
and b[2] for the flavours and 6-flags {b = ±1 for incoming and outgoing 
particles) related to the points P, Pidt, and Pright, respectively. Then the 
following adjustments are made (to allow a matching on the vertices): 

• A priori, if points Pieft or Pright are not yet equipped with a flavour, i.e. if 
they are propagators, their respective &'s will be set to 0. 
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in[l] 



m[0] - 


m[l] 


in[2] 


fi - 


b 




fi - 




b 




b 


fl 


h - 


- fl 


h 


b 


- h 


fl 


b 


- fl 


h 



{cpl[0],cpl[l]} 



in[0] 




in[2] 

Table 6: Vertices witiiin AMEGIC++. Note (1) tlie similarity witli tire point structure 
encountered before and (2) the specific ordering of fermions and anti-fermions. 



• fl[0] is a boson : If b[l] = -1 (b[2] = -1), then fl[l] fl[l] (fl[2] 
fl[2]). If fl[l] or fl[2] are not known yet, b[l] = -1 or b[2] = -1. 

• fl[0] is an anti-fermion : If b[0] ■ b[l] = 1, then fl[l] fl[l]. If fl[l] 
is not known yet, then b[l] = b[0]. 

• f 1 [0] is a fermion : If b[0] ■ b[2] = 1, then f l[2] fl[2]. If f 1 [2] is not 
known yet, then b[2] = b[0]. 

2. Now every vertex available is tested against the - modified - flavours of the 

specific point, i.e. P, Picft, and Pright- Any vertex v passing this test eventually 
defines the flavours of internal lines which then will have to fit themselves. The 
corresponding test is described in the next step. 

3. Let us describe this test for flavour fl[l] related to the point P' = Pieft, 
c.f. Fig. 7. If both its left and its right hnk (denoted by P/gf^. and P/jght) 
are endpoints, all available vertices are tested against them after the following 
transformations: 

• If P' denotes a boson, the flavours of P/gj^ and P/jght will be treated as 
barred and if the corresponding particles are incoming (b = — 1). 

• If P' is an anti-fermion and if b'[0] • b'[l] = 1, then the flavour of P/gj^. will 
be regarded as barred. 

• If P' is a fermion and if b'[0]^, • b'[2] = 1, then the flavour of P/ight is 
barred. 
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If now the modified flavours of any vertex v' fit to the flavours of the points P', 
Pjgf^, and P/ight then this vertex makes an acceptable choice. If any such vertex 
is found, the flavour of P' has passed the test. 

Of course, if either of the two points P{^^^ and P/ight is not an endpoint, the test 
described above is unnecessary. 




Figure 7: Example topology for the mapping procedure. 



3.1.4 Eliminating identical diagrams 

Unfortunately, the algorithms described in the preceeding sections might produce 
identical diagrams, mainly because there is no really sophisticated treatment of iden- 
tical particles and topologies. Within AMEGIC++ therefore, the cure to potential dou- 
ble counting by identical diagrams is explicit comparison of each pair of diagrams. 
This again proceeds recursively by following the point lists of both diagrams under 
test with the following algorithm 

1. If both points pi and p2 to be compared do not have the same number of 
offsprings or have different flavour, the recursion terminates. 

2. The test of step 1 is repeated with pi— >left and p2— >left, and possibly after 
passing with pi— >right and p2— >right. 
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3. If the test of step 2 yields a negative result, then there is still the possibility 
of double counting due to identical particles. To catch this the flavours of 
Pi, 2 — ^ {left, right} are checked crosswise. If this test is passed, i.e. if the 
flavours of pi — >right and p2 — >lef t and of pi — >lef t and p2 — >right mutually 
agree, step 1 is repeated with both combinations. 

4. Finally, if the recursion does not terminate before all points were tested, the 
diagrams are identical and the second one will be discarded. 

3.2 Translation into helicity amplitudes 

In this section, we will turn our focus on the translation of the generated Feynman 
diagrams into corresponding helicity amplitudes and on some items concerning their 
evaluation once a set of external momenta is given. The following issues will be 
discussed in some detail: 

1. The treatment of the momentum flow along the spinor lines, 

2. the piecewise conversion of the diagrams into corresponding Z-functions, 

3. and the evaluation of the helicity amplitudes. 
3.2.1 Spinor direction and momentum flow 

Having generated Feynman diagrams including relative factors of —1 for the exchange 
of two identical fermions, we are now in the position to construct the corresponding 
helicity amplitudes. However, there's a caveat here, since another source of relative 
phases of —1 has not been discussed yet. These additional factors stem from a 
mismatch of momentum and spinor flow along a line. To illustrate this point, consider 
the diagrams exhibited in Fig. 8. Obviously, the sign of the momentum of each 
fermion line, either external or intermediate, is deflned with respect to the spin 
direction. This results for instance in spinors v{—p5) for the incoming positron in 
the graphs depicted in Fig. 8. 

Coming back to the construction of Feynman amplitudes described above, the 
flavours of the point lists are given as in Fig. 9. For all but the leftmost fermion 
lines, a general rule can be formulated as follows: 

• If a point p has an incoming boson as flavour, and if p^lef t is an intermediate 
fermion line (with number 100 or larger), then the overall sign of the diagram 
is multiplied by —1. 

This rule relies only on the fact that for incoming boson lines, there is a strict ordering 
of outgoing fermion lines with respect to particles/anti- particles. This ordering im- 
mediately allows to extract information about the alignment of spin and momentum 
flow along the hues. 
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Pi 



-P5)7m- 



(P2 +P3)^ 



^ Pi 



1 



iMpo) 



{P3 + Pif 

e~(p2)e+(p4)7(Pi)7(P3) 



and 



Figure 8: Example graphs for the process e~{pQ)e^(p^) 
the spinorial part of the ampUtudes. Clearly, there is a difference in the sign of both 
diagrams due to the misalignment of momentum and spin-flow in the left diagram. Note 
that t— channel like topologies emerging from exchanging incoming e"*" and outgoing e~ do 
not alter the overall signs of the propagators. Instead, they merely lead to a replacement 
V2 ^ -P5- 



However, the rule above is of somewhat limited use only, since apparently the 
leftmost fermion line, i.e. the one starting at the point p [0] is not dealt with. Ac- 
cording to the algorithms employed for the construction of the amplitudes, the first 
point of this line, p [0] , is occupied by an incoming particle. 

The leftmost fermion line, i.e. the line starting at the first point, might contribute 
a change of sign, if it starts with an incoming particle represented by an li-spinor or 
with an outgoing anti-particle represented by a f-spinor. Then the corresponding 
endpoint of the spinor line has to be found. This endpoint is then represented by 
either an -u or a ■D-spinor, i.e. it is either an outgoing particle or an incoming anti- 
particle. 

3.2.2 Finding the appropriate Z— functions 

Now we are in the position to present the algorithms leading finally to the helicity 
amplitudes, or in other words, to the appropriate products of Z-functions. This 
proceeds in two steps : 

1. Projecting the point list onto the larger building blocks, i.e. pieces with a 
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b=-l 



e", 
b=-l 



right 



b=i 



right 



e+ b=-l 



right 
I 

left 

I Xb=-1 

right 

I e-, b=l 



e , 
b=-l 



right 



b=l 

left 



Y b=-l 



e', 
b=l 



right 



'i:b=i 



ie+b=-l 



right 



e-, b=l 



Figure 9: Assignments for the point lists corresponding to the graphs in Fig. 8. Note that 
on the level of point lists, the i-channel topologies differ only in their endpoints. 



number of intermediate vector and scalar bosons, and 

2. flipping the arguments of the emerging Z-functions, such that the particles 
associated with a "barred" spinor are always followed by particles with "un- 
barred" spinors. This point applies for the spinors constituting the polarization 
vectors of spin-1 bosons as well. 

We will now elucidate the two steps above. For a 
better understanding of the projection algorithm 
mapping the point lists onto helicity amplitudes 
we recall briefly the structure of the basic building 
blocks available within AMEGIC++. Schematically, 
they can be represented like in the figure on the 
right. They all consist of a number of boson prop- 
agators - the wiggly lines - between fermion prop- 
agators or external spinors, related to fermions or 
their polarization vectors, represented by the ar- 
rowed straight lines. The blob in the middle then 
represents all possible Lorentz-structures connect- 
ing the boson propagators. 

These building blocks naturally emerge, because intermediate fermion lines can be cut 
by use of the completeness relation, cf. Eq. (2.12), while vector boson hues cannot 
be cut in such a way. These considerations lead straightforward to the algorithm 
employed in the mapping procedure sketched below: 
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1. Start with a point p. Check, if the particle related to this point is either 
an external or an intermediate fermion (with p— >lef t a boson and p— aright 
a fermion), an external or intermediate anti-fermion (with p— >left an anti- 
fermion and p— >right a boson) or an external boson. This condition ensures 
that 

(a) a reasonable translation is possible at all, where the ordering of the con- 
nected points for incoming fermions or anti-fermions is just another check, 
and that 

(b) intermediate boson lines are not double counted. 

If the conditions above are met, the boson is selected and the steps 2 and 3 are 
executed. 

2. Starting from the boson, the hnks of the subsequent points are followed recur- 
sively along possibly occurring further bosons. In every boson line branching 
into two fermions this recursion terminates. By this procedure, the number 
of bosons, their type and their topological connections are explored. These 
characteristics determine which of the building blocks exhibited in Figs. 1, 2, 
and 3 are to be used. 

3. Having determined the structure of the building block, the task left for the 
translation of this particular piece is to fill in the corresponding arguments and 
couplings. 

4. The procedure is repeated with the points p— >lef t and p— aright. 

Unfortunately, this procedure does not care about any ordering of spinors coming into 
play either via external particles or their polarizations or by using the completeness 
relation on the intermediate fermion lines. Let us illustrate this by considering the 
amphtude depicted in Fig. 10 

We see immediately that the particle indices occur in ordered pairs of the form {u, u}. 
However, within AMEGIC++, this ordering of the spinor pieces against the spin flow is 
mandatory but is not necessarily realized immediately after the construction of the 
helicity amplitudes. Hence, after being constructed, the Z-functions are searched 
for external fermions or anti-fermions not obeying the ordering u, u. If found, the 
indices within the corresponding pair are switched. If the partner-index denotes a 
propagator, the index occurs twice due to the completeness relation. Consequently 
it has to appear exactly once on the first and on the second position of such a pair. 
This is taken care of by switching the sequence in the other Z-function in which this 
particular index appears. 
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Z^[101, 0; 3, 2]Z^[1, 101; . . .] 



Figure 10: Example diagram for flipping the ordering of spinors within Z-functions. 
3.2.3 Evaluation of the amplitudes 

As the last item related to the helicity amplitudes, we discuss briefly, how for a 
given set of external momenta and helicities a particular amplitude is evaluated. 
The key point to notice here is that we cut open the fermion lines by use of the 
completeness relation Eq. (2.12). Thus for each intermediate fermion line a sum 
over both helicities and both particle and anti-particle type spinors (uu and vv, 
respectively) has to be performed. For massive particles, the masses of the u- and 
the V- spinors are connected with different signs, entering finally the Z-functions. 
Therefore, the internal fermion lines are counted first, then for each internal fermion 
line two summation indices are introduced, labeling the two helicities and the particle 
and anti-particle components, respectively. For each combination of these indices, 
the corresponding spinor labels are filled into the Z-functions, and a minus sign 
internally labels anti-particles and will be recognized at the level of the building 
blocks to alter the sign of the corresponding mass. Finally, for each combination of 
internal helicities and particle anti-particle labels all building blocks are multiplied 
separately to be summed. 

3.3 Generation of integration channels 

Let us turn now to the generation of additional channels for the multi-channel phase 
space integration performed by AMEGIC++. As already explained in Sec. 2, for the 
definition of efficient integration channels it is essential to know as much as possi- 
ble about the structure of the integrand, i.e. possible (in the Monte Carlo sense) 
singularities in phase space. For AMEGIC++, this proves to be the case, because the 
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Feynman diagrams are already at hand. So, basically, the steps performed within 
AMEGIC++ for the construction of channels are: 

1. For each Feynman diagram the internal lines are identified and it is decided, 
whether they are in the s- or in the ^-channel, 

2. then the propagators and decays are translated according to their properties 
into the building blocks listed in Tab. 4, 

3. finally a subset of the individual channels (each corresponding to one specific 
diagram) is selected. 

3.3.1 Properties of the internal lines 

The first step in the construction of an integration channel for a particular Feynman 
diagram is to decide, in which kinematical region the individual propagators are, i.e. 
whether they are s- or t-channel propagators. This again is done recursively starting 
from position 1 in the list of linked points constituting the diagram. By iterative 
steps to the left and right hnks the other endpoint with b — —1, i.e. the other 
endpoint related to the second incoming particle is found. In these iterative steps, 
connections to the corresponding previous points are set. It is then straightforward 
to follow their track back to the starting point, equipping each propagator on the 
way with a flag indicating that this is a t-channel propagator. More graphically, 
this identification amounts to a "redrawing the diagram with t-channels running 
vertically and s-channels running horizontally", see Fig. 11. 



c 




Figure 11: Identifying the propagator types for a process A + B^C + D + E + F + G. 
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3.3.2 Construction of channels 

Now we are in the position to construct appropriate channels. The steps here are 
the following: 

1. Depending on the number of i-channel propagators, the construction of chan- 
nels in principle starts either with an isotropic two-body decay, with a t- 
channel propagator or with an isotropic three-body decay (for rit — 0, 1, 2, 
respectively) . 

2. The first task when implementing any decay then is to determine the (virtual) 
masses of the decay products. This is achieved in the following way: 

• First, decay products which are outgoing particles in the process under 
consideration arc put on their mass-shell. 

• Then, decay products which are propagators are equipped with a virtual 
mass squared s. It satisfies Smin < s < s^ax and is distributed either 
according to a single pole (massless propagators, i.e. propagators with 
mass rrip < Smin) or according to a Breit-Wigner distribution (massive 
propagators, i.e. rrip > Smin)- 

The limits of the virtual mass squared s are given by the following con- 
siderations: y/s obviously should be larger than the sum of the masses 
of all outgoing particles produced in the subsequent decays of the propa- 
gators. In turn, a/s running in a propagator should be smaller than the 
energy squared entering the production vertex of the propagator minus 
the masses of the other propagators which are already chosen, and minus 
the minimum masses of the propagators with yet undefined masses. 

3. After having chosen in the first step the basic form of the channel, i.e. the form 
of the first decay, the subsequent decays are filled in recursively. By default, 
for the secondary decays, only isotropic and anisotropic two-body decays are 
available. Again, the momentum transfer squared along the propagators is 
chosen according to the step above. This procedure of decays and propagators 
is iterated until only outgoing particles remain. 

As an example, let us consider the diagram depicted in Fig. 12, contributing to the 
process e~^e~ scfi/r^. Let us assume for better illustration that both propagators 
CD and EFG are resonating with Mcd^cd > Mefg^efg (in fact, in our example 
process the two products are identical). 

The corresponding channel is constructed in the following way: 

1. Counting the number of i-channel propagators, we find rit — l. Therefore the 
basic form of the channel is determined to be of the simple i-channel form. 
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Figure 12: One of the diagrams related to the process e+e — scrVr^f- 

2. With s = {pa + PbY we find the following minimal and maximal momentum 
transfers: 

«Sfn = {mc + mnf , s^^ = (^/^ - 

(3.1) 

Then s^^^ is chosen first within its limits as given in the equations above, 
and only then s*^^ is determined, with s^f^ replaced by s^^^. These virtual 
masses for the propagators enter the t-channel decay of step 1. 

3. We continue along the CD-propagator. Since both particles C and D are 
fermions, the decay of CD ^ C + D is translated as an isotropic two-body 
decay. 

4. Let us follow now the E'FG-line, and consider the radiation of particle E, a 
photon, off this line. As it is well known, massless vector bosons tend to have 
an enhancement in the coUinear and soft region of emission. Therefore, this 
decay will be described via an anisotropic two-body decay within the channel. 

5. Finally, since particles F and G are fermions, as depicted in our example, their 
decay is described by an isotropic two-body decay. 

The corresponding code generated by AMEGIC++ for this specific channel can be found 
in Appendix A. 

3.3.3 Selection of channels 

Having generated one channel for each diagram, two things become pretty obvious 
during integration: 
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1. Not all diagrams are equally singular, i.e. some of the channels are more effec- 
tive, whereas others almost do not contribute. 



2. Having too many channels, the multi-channel method is not awfully efficient. 
The various - and often irrelevant - channels are "stealing" a priori weights 
from each other and from the good, relevant channels. 

To alleviate this situation, in AMEGIC++, some selection of good channels is performed 
before the integration starts. Depending on the cm. energy available for this process, 
the propagators which yield the singular behavior, are examined for each channel. 
The maximal number of potentially resonant propagators is determined for each 
channel, and the most "successful" channels in this category are used in the phase 
space integration. 
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4. Implementation 



Basically, the determination of cross sections which is the main task of AMEGIC++, 
can be divided into three major stages: 

1. The input has to be classified, i.e. the process(es) to be calculated as well as 
the framework of the model must be determined. At this stage incoming and 
outgoing particles are specified, particle spectra and couplings are determined, 
the Feynman rules are established and eventually, using these Feynman rules, 
particle widths are calculated. Actually, this last step already invokes the other 
two stages, i.e. generation of Feynman amplitudes and their integration. 

2. Now, having estabhshed the model framework, the Feynman diagrams related 
to each single process have to be constructed and translated into helicity am- 
plitudes. Hence, the scattering amplitude is nearly ready for integration. But 
since some of the helicity combinations yield exactly zero, the calculation can 
be much alleviated, when these parts are eliminated beforehand. Additionally, 
the amplitude can be compactified analytically by common factors. These ma- 
nipulations are performed by translating the expression for the amplitude into 
a character string and simplify this character string accordingly. Now, evalu- 
ating an amplitude for given external momenta means to interpret a character 
string. Saving this very string into a C++ library file and linking this file to- 
gether with the main program speeds up the calculation considerably. This is 
the last refining of the amplitudes, and they are ready for integration. 

3. Finally, the scattering amphtude has to be integrated by Monte Carlo methods. 
Hence, the final step consists of the random generation of phase space points, 
i.e. of sets of four-momenta for the outgoing particles and their summation in 
order to obtain the cross section. This task could be easily achieved, if the 
amplitude was uniform in the whole phase space and would not possess any 
divergencies in the Monte Carlo sense, i.e. sharp peaks. However, as usual life 
is much more difficult than one might wish and scattering amplitudes tend 
to have an abundance of peaks in regions, where particles become either soft, 
coUinear or resonant. The mapping of the uniform and flat distribution of 
phase space points onto a structure which suits the one of the amplitude, is 
crucial for the phase space integration. 

Following these three major steps, this chapter is structured as follows: In analogy 
to the first stage, we first describe in Sec. 4.1, how the overall organization of the 
whole program works out, and how the processes are set up. Then, in Sec. 4.2 we 
discuss the way, the model under consideration enters. In Sec. 4.3, we then turn our 
attention to the generation of Feynman diagrams and their translation into helicity 
amphtudes. The next section. Sec. 4.4, is dedicated to the subsequent treatment of 
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these amplitudes in terms of character strings. Here some of the secrets of the ancient 
kabbalistic system will be disclosed. The final integration over the whole phase 
space will be discussed in the next section, Sec. 4.5. Last but not least a lot of small 
helper routines must be provided for accomplishing all tasks. Their explanation as 
well as the description of the system of parameters and switches will complete this 
chapter with its last two sections. 

4.1 Organization 

The central class steering all processes, i.e. the class which is used within the main 
routine, is called unsurprisingly Amegic. During the initialization part it specifies 
the model, i.e. the Feynman rules, starts the calculation of the decay widths and 
branching ratios of unstable particles, determines all possible topologies up to a 
certain maximum number of outgoing legs and initializes the individual processes by 
reading in the incoming and outgoing particles. Therefore it employs all the other 
major classes of the program, see Fig. 13. 

Specific details of the initialization of the chosen model can be found in Sec. 4.2, 
whereas the other classes will be described in this section. A brief outline of the 
classes discussed in this section can be found in Tab. 7. 

4.1.1 Organizing the Organization - Amegic 

The class Amegic contains the following methods : 

1. The Constructor of this class runs the whole initialization procedure of the 
program along the following steps: 

• The model file which has been chosen from the input parameters, is spec- 
ified and initialized. During this stage the spectrum of the model is de- 
termined. 

• The vertices which are in fact the Feynman rules deduced by the model 
are initialized. 

• The processes to be calculated are read in from the Process . dat data file 
with the help of Read_Processes () . The incoming and outgoing particles 
for the different processes are fixed. 

• Having at hand the maximum number of external legs the raw topologies 
can be determined by constructing a Topology object. 

• For every particle which is marked as unstable in the Particle.dat 
data file, the total width and the branching ratios have to be calcu- 
lated using the Decay_Handler. With Decay_Handler : : Find_Unstable () 
all unstable particles are detected and listed in a DecayTable. Now, 
Decay_Handler : : Calculate () evaluates the width and the branching 
fractions of the particles. 
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Class/Struct 


Purpose 


Amegic 


Main class, reads in the process parameters. 


Decay_Handler 


Handles all decays of the unstable particles, 




calculates widths and branching ratios. 


DecayTable 


The table of decay chains. 


Process 


Mother class of all processes. 


AlLProcesses 


Maintains a number of processes. 


Single_Process 


Maintains the initialization and calculation of 




one single process. 


Amplitude_Base 


Container for all integrable amplitudes. 


Helicity 


Determines the helicity combinations yielding 




a non-zero result. Explores and uses symmetries. 




i.e. identical results for different helicity 




combinations. 


struct signlist 


List of helicity signs, contains on-switches. 


Polarisation 


Provides the polarisation vectors of external bosons. 


Point 


A point structure for building binary trees. 


Topology 


Calculates all possible topologies. 


Single_Topology 


Contains a single topology. 



Table 7: A short description of the major classes handling the organization of AMEGIC++. 

• Last but not least the individual processes will be initialized via 

Process: :Init(). Consequently the raw topologies are combined with 
the vertices yielding the Feynman diagrams which are then translated into 
helicity amplitudes. 

2. Read_Processes() reads in the list of processes from Process.dat, extracts 
the flavours with the help of Extract_Flavours(), and groups the processes 
into All_Processes. If only one process is to be considered, a Single_Process 
will be created instead. 

3. In Extract_Flavours() the raw text given in the Process.dat data file is 
translated into the numbers and fiavours of the incoming and outgoing particles. 

4. Run() calculates the total cross section of all involved processes via 
Process: :Sigma_Total(). 

4.1.2 Decays - Decay_Handler 

The primary aim of the Decay_Handler is to generate a DecayTable containing all 
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Figure 13: Main structure of the program. 



information concerning the decays of unstable particles, i.e. total widths, branching 
ratios, the flavour of the decay products etc.. The DecayTable is constructed as a 
two-fold list in the following way. 
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Every entry into the DecayTable itself is a DecayTable, 
having pointers into two directions (see Figure to the 
right): 

1. Next, pointing to the next decaying particle or the 
next decay channel, and 

2. More, pointing to a list of decay channels for the 
same decaying particle. 



w 



More 



d;u 



Next 



Next 



s;c 



Next 



More 



u;u 



Next 



Next 



Furthermore, each DecayTable has a varying (limited by 
the user) number of flavours, the flavour of the decaying 
particle plus the flavours of its decay products. The 
user defines the maximal number of particles created in 
a decay. If, in the process of setting up the DecayTable, 
a particle decays into a final state consisting of one or 
more unstable particles, these can be then replaced by 
their own decay products. 

Now we are in the position to understand, how the Decay .Handler fills this table via 
the following methods : 



c;c 



Next 



1. Find_Unstable() produces the list of all unstable particles, where the decay 
width has to be calculated. A simple loop over all particles probes their on- 
switch which is read in from the Particle.dat data file, i.e. whether the user 
wants to include them or not. Discarded particles are neglected completely, 
so they do not show up, neither as internal nor as external lines. Having at 
hand all decaying particles the products will be determined with the routines 
Find_Decay_Products_2() for the 1^2 decays and Find_Decay_Products_3() 
for any further decays. 

2. Find_Decay_Products_2() finds every 1-^2 decay for the unstable particles. 
Naively, one could take every possible pair of particles as decay products. But 
applying a number of constraints, only decays with non-zero width are taken 
into account. Thus every pair of decay products has to obey the following 
restrictions: 



• The incoming flavour has to interact at all, so it has to show up in the list 
of vertices as an incoming or outgoing particle, respectively. This test is 
performed with Check_ln_Vertex() . 

• Due to energy-momentum conservation none of the decay products can 
be the same as the incoming particle. 
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• The masses of the decay products must be separately smaller than the 
mass of the incoming particle. The sum of both masses can be larger, if 
one or both of the decay products is unstable and can be understood as 
an internal line. Later on, the decays into such virtual particles is taken 
into account via three or more body decays. 

• All quantum numbers, i.e. charge and spin, have to be conserved. Hence, 
a decay of a fermion into bosons only is disallowed. 

If it fulfills all these constraints the decay channel is added to the Decay! able 
with the help of Add, i.e. another item is added to the More list of the corre- 
sponding decaying particle. 

3. In AddO the last check for a particle and its decay products is performed. With 
the help of Check_Vertex() the three flavours are compared with the flavours 
of all existing vertices in the actual model. Only if this check is passed, a new 
DecayTable is added to the list. 

4. Find_Decay_Products_3() finds any further decay beyond two-body decays. 
Therefore a loop over all already determined decays is performed. In the case 
a virtual particle is found, i.e. the sum of the masses of all decay products is 
larger than the mass of the incoming particle, a further decay of unstable decay 
products is realized with Next_Decay(). 

5. Next_Decay() is used for the determination of further decays. Now, every 
decay product is analysed once more. If it is an unstable particle itself, one 
can of course find it in the list of decaying particles. A further loop over all 
possible decays of this particle and its replacement by these decay products 
completes the creation of a new decay mode which then will be attached to the 
DecayTable. 

6. Check_In_Vertex() checks, if a certain flavour is included in the list of vertices. 

7. Check_Vertex() checks, if a vertex with the given flavour combination exists. 

8. Calculate () calculates the width of the different decay modes and sets the 
branching ratios. It uses the list of decays which has already been constructed 
in Find_Unstable(), to determine the width of the different decay modes using 
Rec_Calc(). Having at hand all decay widths it is straightforward to calculate 
the different branching ratios with Branching_Ratios(). 

9. Rec_Calc() evaluates the widths of the different decay modes recursively in 
order to take into account the further decay of virtual particles. For the calcu- 
lational part, the routines of Process are utilized. 



42 



10. Branching_Ratios pcrformes a loop over all decaying particles and deter- 
mines the branching ratios with the help of Rec_BR(). 



11. Rec_BR() calculates the branching ratios recursively, since all further decays 
have to be taken into account. 

12. Print () prints the table of decays including the decay widths and branching 
ratios. 

4.1.3 Helicities and Polarisations 

The structure signlist contains one helicity combination, an On-switch and a mul- 
tiplicity. The latter one can be used to reduce the number of helicity combinations 
by dropping equivalent ones, i.e. those yielding the same numerical result. The or- 
ganization is done by the class Helicity via the following methods: 

1. The Constructor determines all helicity combinations using a loop over loops 
technique as described in Appendix C. Having at hand all possible helicity 
combinations with two helicities per outgoing particle, the second helicity for 
scalar particles (which have no hehcity at all) and massive vector bosons (where 
the sum over the polarizations is carried out differently to the massless vector 
bosons) is switched off. 

2. Max_Hel() returns the maximum number of helicities. 

3. operator [] () returns a certain helicity combination. 

4. switch_off () switches a certain helicity combination off. 

5. On() returns the status of a certain helicity combination. 

6. Inc_Mult() increases the multiplicity of a combination by one. 

7. Multiplicity returns the multiplicity of a certain helicity combination. 

The class Polarisation maintains all methods needed in connection with polarisa- 
tions for massless and massive vector bosons: 

1. Spin_Average() The normalization constant for averaging the spin, the color 
and the polarisations of all incoming particles is determined at this stage. Ac- 
cordingly, every fermion yields a factor of 1/2, every quark an extra factor of 
1/3, every gluon a factor of 1/8 and the massless and massive vector bosons 
gain a factor of 1/2 and 1/3, respectively. 

2. Massless_Vectors() determines whether there is any massless vector boson 
in the in- or outstate. If this is the case, an extra four-momentum vector for 
the construction of the polarisation vector is attached to the hst of vectors. 
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3. Massive_Vectors counts the number of massive vector bosons in the in- and 
outstate. For every hit two new four-momenta are attached, see Eq. (2.18). 
The change of the normahzation is performed according to Eq. (2.20). 

4. In Attach a connection between the massive vector boson and its two po- 
larisation vectors is drawn, ensuring that the latter ones add up to the vector 
boson momentum. 

5. Reset_Gauge_Vectors() changes the extra gauge vector, when massless vector 
bosons are present. Usually, this routine is used during the gauge test. 

6. Set_Gauge_Vectors() sets the gauge vector of the massless vector boson and 
calculates the two polarization vectors for each massive vector boson. The lat- 
ter ones are determined according to Eq. (2.18) along the following algorithm : 
The four-momentum of the massive vector boson is boosted into its rest frame 

and two massless four-momenta are generated as uniformly distributed mass- 
less pseudo-decay products of the vector boson. Afterwards they are boosted 
back into the lab frame. 

7. Massless_Norm() calculates the normalization due to massless vector bosons, 
see Eq. (2.16). 

8. Massive_Norm() yields the normalization due to massive vector bosons, see 
Eq. (2.20). 

9. Replace_Numbers : During the translation of the Fcynman diagrams into he- 
licity amplitudes all polarisation vectors obtain dummy numbers. The correct 
connection to the appropriate polarisation vector is performed in this rou- 
tine utilizing Single_Amplitud.e : :MPolconvert () . As described above, mas- 
sive vector bosons are treated as propagators decaying into their - massless 
- polarisation vectors, the respective changes are carried out with the help of 
Single_Amplitude : : Prop_Replace () . 

4.1.4 Handling of processes 

The two main classes concerning the overall handling of processes are All_Processes 
and Single_Process. Both classes provide the amplitudes squared, either for a list 
of processes or for a single process, respectively. In order to integrate both with the 
Phase_Space_Handler they have to be derived from the class Amplitude_Base which 
is the base of an (phase space) integrable class. Therefore, its purely virtual operator 
operator () () must be overwritten by the appropriate inherited class. On the other 
hand, the two process classes have to provide a similar interface which simplifies the 
usage from outside. Accordingly, both classes are derived from a mother class called 
Process, a virtual class which contains a minimal set of routines, i.e. InitO, for 
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Figure 14: One single Process containing an amplitude and a phase space evaluation. 



the initialization, Sigma_Total() for the calculation of the total cross section and 
AddO for adding a new process to All_Processes. Since all these methods have to 
be overwritten by the derived class, a detailed description can be found there. 
The container for a hst of processes is All_Processes: 

1. Within the Constructor () the maximum number of processes is set and a 
blank list of Single_Processes is generated. 

2. InitO performs a loop over all processes and initializes them via 
Single_Process : : Init () . 

3. Sigma_Total() evaluates the individual cross sections for all processes and 
adds them up. At this stage a parallelization of the calculation for the different 
processes would enhance the performance. This is part of a future project. 

4. The operator () is inherited from Aniplitude_Base and is used for integrat- 
ing the sum over all cross sections. Accordingly a loop and a sum over all 
Single_Process : : operator () ()s is done. 
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5. AddO appends another process to the hst. 

The organization, i.e. the initiahzation as well as the calculation of the amplitude 
squared for single process lies in the hands of the class Single_Process: 

1. The Constructor of the class covers a large part of the initialization proce- 
dure which is accomplished along : 

• The sequence of the flavours for the incoming and outgoing particles is 
reshuffled using the routine reshuffle (). 

• A string which identifies the given process unambiguously, is generated 
via set_ID(). 

• A directory is created named with this ID. It will contain all the output 
from this process. 

• The overall normalization is calculated using Symmetry_f actors () and 
Polarization: : Spin_Average () taking into account the symmetry fac- 
tor due to permutations of outgoing particles and the average over the 
incoming quantum numbers, respectively. 

• The number of polarization vectors is determined, exploring the massless 
and massive vector bosons with Polarization: :Massless_Vectors() and 
Polarization: :Massive_Vectors(), respectively. Now, the number of 
four-momenta is simply the sum of the number of incoming and outgoing 
particles plus the number of polarization vectors needed. 

• With Polarization: :Attach() the polarization vectors of the massive 
vector bosons are connected with the appropriate vector boson. 

• The normalization due to the special treatment of massive vector bosons 
is calculated via Polarization: :Massive_Norm(). 

• Now, all helicity combinations are determined by constructing the Helicity 
object. 

• The basic functions for the determination of the building blocks, i.e. 
the S-functions (see Eq. (2.23)), will be initiahzed by constructing a 
Basic_Sfuncs object. 

• Last but not least the String_Handler for the generation and translation 
of the helicity amplitudes into character strings is constructed. 

2. Now, the method InitO has only a small task left, since the bulk of initial- 
izations has been already carried out. This task is the construction of the 
Ainplitude_Handler object and the initialization of the S-functions and the 
String_Handler via the appropriate routines Basic_Sf uncs : : Initialize () 
and String_Handler : : InitO, respectively. 
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3. In reshuffle () the user-given sequence of the input flavours is changed to an 
intrinsic standard. The internal order in AMEGIC++ is fermions before bosons. 
Then, particles are first ordered according to the absolute value of their kf-code 
and particles are always listed before anti-particles. Massless vector bosons 
are hsted at the end of the hne which is closely related to the treatment of 
polarization vectors within the program. 

4. set_ID() constructs the uniquely defined process name. The simple rule is 
that at first the number of incoming and outgoing particles is translated to the 
character string. At next the flavours of these particles follow. An example 
can be found in the Test Run Output, see Appendix D. 

5. The Symmetry _f actors for outgoing particles are constructed from the mul- 
tiplicity n of a flavour, where every multiple occurrence gains a factor of l/n\. 

6. Tests contains two different tests of the derived amplitude. First of all, a 
gauge test can be performed, if massless vector bosons are present. In this 
case, the amplitude is calculated with two different choices of the correspond- 
ing gauge vectors and the results will be compared. Of course, if the program 
is doing everything correct, this test should be passed, i.e. both results should 
coincide for every single combination of external, physical momenta. Taken by 
itself, this test provides a powerful tool for checking amplitudes, vertices etc.. 
Therefore it might be useful sometimes to add a photon or a gluon to a process 
to have this kind of test at hand. The next test concerns the translation of the 
helicity amplitudes into character strings. During this translation numerically 
small parts will be neglected and the emerging string will be reorganized and 
simplified. Therefore, a test for the correctness of the string is urgently nec- 
essary. Again, the amplitudes calculated with and without the string method 
are to be compared. 

7. Sigma_Total calculates the total cross section for the given process utiliz- 
ing the class Phase_Space_Handler. After constructing this object the method 
Phase_Space_Handler : :Create_Integrator() builds all the possible integra- 
tion channels. With Phase_Space_Handler : : Integrate () the calculation of 
the total cross section is achieved. 

8. The operator () yields the amplitude squared for a given configuration of 
four-momenta for the incoming and outgoing particles. The first step in this 
calculation consists of setting the gauge vector. Then, a loop over all possible 
helicity combinations is performed and the different values for the individual 
amplitudes are summed up. Multiplying the result with the normalization 
for the gauge vector derived from Polarization: :Massless_Norm() and the 
overall normalization gives the amplitude squared. 
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4.1.5 Construction of topologies 

The class Point contains all information about a specific vertex, i.e. pointers to 
the left and to the right next Point, the flavour, the particle or propagator 
number etc.. In this way a tree structure can be generated by means of linked 
Points. Accordingly, all topologies with the same number of legs are contained in a 
Single_Topology, other variables are the number of legs, the depth as well as the list 
of Point lists. The class Topology creates and handles a list of Single_Topologys 
(which differ by the number of legs) via: 

1. The Constructor () constructs all topologies with the method Build_All(). 

2. Build_All() generates all topologies up to a maximum number of legs. It 
starts by initializing the first simple topology with one external leg only. Since 
every topology contains all other topologies with a smaller number of external 
legs, it is created recursively out of those by calling Build_Single() . 

3. Build_Single() builds all topologies for a certain number of external legs, for 
details concerning the algorithm see Sec. 3.1. 

4. GetO returns a list of topologies with a certain number of legs. 

5. CopyO copies a given point list into another. 

6. Print prints a topology. 

4.2 The Model 

Cross sections are calculated within the framework of a specific model, i.e. they 
depend on a set of assumptions and parameters like the particle spectrum and the 
properties (quantum numbers) of the particles as well as their interactions defined via 
vertices and the corresponding coupling constants. Strictly speaking, this framework 
is defined by the underlying Lagrangian, from which the parameters can be either 
read off or calculated. However, for the sake of implementing such a model in terms 
of computer algorithms, it is sensible to divide the information defining the model 
into several pieces, reflected by the class structure. In general, in AMEGIC++ particle 
properties are handled by the class Flavour, interactions are governed by the classes 
Model and Vertex, and the appropriate (possibly running) coupling constants and 
the particle masses are generated by Coupling and Spectrum classes, respectively. 

A brief outline of all the classes mentioned above, can be found in Tab. 8. The 
different methods of the classes are described in detail in the subsequent sections, 
covering the complexes Flavour, Vertices, Model, Spectrum and Couphngs. 
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Class/Struct 


Purpose 


kf 


Connects the kf-code of every particle with a name. 


kLtoJnt 


Translates the kf-code into an integer value. 


partJnfo 


Contains all the information about a particle 




which is read in from the Particle.dat data file. 


Flavour 


All particle properties are handled from here. 


flJter 


An iterator over all possible flavours is often useful. 


Single_Vertex 


Contains all information about a Feynman rule. 


Vertex 


Maintains the initialization of the vertices, 




i.e. the Feynman rules of the chosen model. 


Model 


Is the virtual mother class of all models. 


ModeLQCD 


Contains the QCD Feynman rules. 


ModeLEE_QCD 


Contains the QCD Feynman rules plus a coupling of the 




QCD particles to electron and positron. 


ModeLEW 


Contains all electrowcak Feynman rules. 


ModeLSM 


The complete Standard Model can be found here. 


Spectrum_EW 


The electrowcak spectrum, i.e. all masses of the leptons 




and gauge bosons are maintained here. 


Spectrum_QCD 


The QCD spectrum, i.e. the masses of the quarks is 




read in within this class. 


Couplings_EW 


The electrowcak coupling constants as well as their 




running is performed within this class. 


Couplings_QCD 


The running of the strong coupling constant is calculated. 



Table 8: Principal classes to set up and organize the physical framework. 



4.2.1 The Flavour 

kf contains the kf-code of every particle according to the PDG [21], whereas the 
small class kf _to_int translates this kf-code into an integer value and back. All 
necessary particle information is stored in part_inf o, namely the kf-code, the mass 
and width, the charge and the isoweak charge, a flag for strong interacting particles, 
the spin, a flag for the majorana character of a particle, an on-switch, a flag for stable 
particles and the name of the particle. The class Flavour handles all properties a 
particle could have. Therefore, it mainly provides routines for obtaining information 
about a particle type: 

1. texnameO gives the name of a particle in a LaTeX format. This is used for 
instance by Vertex: :Tex_Output(). 
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2. kf codeO gives the kf-code of a particle. 

3. The operator int() returns the integer value of a kf-code. A minus sign 
covers the possible anti-particle nature. 

4. barO returns the anti-particle of a particle. 

5. charge returns the electromagnetic charge in units of the proton charge. 

6. i charge () returns as an integer three times the electromagnetic charge. 

7. isoweakO returns the value of T3, the third component of the weak isospin. 

8. strong () yields 1, if the particle interacts via the strong force. 

9. spinO returns the spin of a particle. 

10. ispinO returns as integer twice the spin of a particle. 

11. isonO returns 1, if a particle should take part in the generation of the Feynman 
rules. 

12. isstableO is the switch which returns 1 in case the particle width should be 
calculated by the program, otherwise the width stored within the Particle . dat 
data file is used. 

13. set_on() switches a particle on. 

14. massO returns the mass of a particle. 

15. setjnassO sets the mass of a particle. 

16. width () returns the width of a particle. 

17. set_width() sets the width of a particle. 

18. nameO returns the character name of a particle. 

19. isf ermionO returns 1, if the particle is a fermion. 

20. isbosonO returns 1, if the particle is a boson. 

21. isscalarO returns 1, if the particle is a scalar, i.e. if it has spin zero. 

22. isvectorO returns 1, if the particle is a vector, i.e. if it has spin one. 

23. isquarkO returns 1, if the particle is a (anti-) quark. 

24. isgluonO returns 1, if the particle is a gluon. 
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25. isleptonO returns 1, if the particle is a (anti-) lepton. 

26. isuptypeO returns 1, if the particle is up-type. Note that this extends to 
leptons and neutrinos as well. 

27. isdowntypeO returns 1, if the particle is down-type. Note that this extends 
to leptons and neutrinos as well. 

28. isantiO returns 1, if it is an anti-particle. 

29. hepevtO returns the HEPEVT kf-code. 

30. fromJiepevt () sets the flavour according to the HEPEVT kf-code. 

The class f l_iter provides an iterator over all particles in the particle data table. 
Two methods, i.e. First and Next return the first and the appropriate next particle, 
respectively. 

4.2.2 The Vertices 

A Single_Vertex contains all information about an 1 ^ 2 Fcynman rule, i.e. the 
three flavours, the left- and right-handed coupling constants and a possible repre- 
sentation by a character string. The class Vertex handles the generation of Feynman 
rules utilizing some of the methods from the class Model. 

1. The ConstructorO builds the list of vertices (Single_Vertex) and produces 
a LaTeX output file. First of all, the hst is filled via the Model routines c_FFV, 
c_FFS, c_VVV,c_SSV, c_VVS and c_SSS, see Tab. 9. Having at hand all the differ- 
ent vertices, the LaTeX output is generated with Tex_Output ( ) . Since during 
the matching of the vertices onto the raw topologies not only the standard form 
of a vertex is used, but also its rotations (obtained as a combination of permu- 
tating the flavours and taking their anti- flavours), every vertex is transformed 
into the six possible combinations with an appropriate change of the couplings, 
see Tab. 6. A test with Check_Equal () prevents any double counting of already 
generated vertices. 

2. Check_Equal compares any combination of three flavours generated in the 
process of initialization with all already generated vertices and prevents any 
double counting. 

3. Print prints the list of vertices. 

4. operator [] () returns a Single_Vertex from its number. 

5. Max_Number() returns the maximal number of vertices. 
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Figure 15: A sample vertex in LaTeX output form. Note that Pr and Pl are the right 
and left handed projectors including a 7^1^. 

6. Tex_Output() generates a LaTeX output of all Feynman rules. The character 
strings generated for each vertex in the model classes will be combined with a 
FeynMF [22] picture of a vertex, for example see Fig. 15. 

7. AddVertexO adds a Single_Vertex to the hst of vertices. 

8. FindVertexO searches for a given Single_Vertex in the list of vertices and 
returns its number. 



4.2.3 The Model 

The Model class represents the basis for all other model classes which are simply 
derivatives. Consequently, most methods are purely virtual. However, they play a 
similar role in every model and therefore, they will be described only once. The first 
part is dedicated to the initialization of the model and the vertices: 

1. Init_Vertex() generates the hst of vertices by constructing the Vertex object. 

2. Get_Vertex() returns the list of vertices. 

3. Usually InitO generates the masses and couplings of the given model with 
the help of an appropriate Spectrum and Coupling class, respectively. 

All Feynman rules can be classified according to their Lorentz structure which de- 
pends on the incoming and outgoing flavours. This classification scheme of the 
vertices in AMEGIC++ is depicted in Tab. 9, the methods listed there are then filled 
in a model dependent way. Since the Model class contains not only all the Feynman 
rules, but also the different coupling constants some helper methods permit to gather 
this information: 
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Method 


Incoming 


Left Outgoing 


Right Outgoing 


c_FFV() 


Fermion 


Vector boson 


Fermion 


c_FFS() 


Fermion 


Scalar boson 


Fermion 


c_VW() 


Vector boson 


Vector boson 


Vector boson 


c_SSV() 


Scalar boson 


Vector boson 


Scalar boson 


c_VVS() 


Vector boson 


Scalar boson 


Vector boson 


c_SSS() 


Scalar boson 


Scalar boson 


Scalar boson 



Table 9: Connection of methods for the initialization of vertices with the external particles. 



1. SinTWO returns the sin 

2. CosTWO returns the cos^vk- 

3. AqedO returns oqed at the CM energy scale. 

4. Aqed(double) returns ckqed at the given scale. 

5. AqcdO returns ckqcd at the CM energy scale. 

6. Aqcd (double) returns ckqcd at the given scale. 

The different model classes which are derived from the main class Model, can be 
characterized via the Feynman rules (i.e. vertices) they initialize: 

1. Model_QCD contains all pure QCD Feynman rules, i.e. the interaction of quarks 
via gluons and the gluon self-interaction in the axial gauge. 

2. Model_EE_QCD includes all vertices from Model_QCD plus the interaction of quarks 
with electrons and positrons via photons and Z bosons. 

3. Model_EW includes all electroweak vertices, i.e. the interaction of all Standard 
Model particles via photons, Z, W and Higgs bosons. 

4. Model_SM combines Model_QCD and Model_EW to yield all interactions of the 
Standard Model. 



4.2.4 The Spectrum 

The two different spectra of the Standard Model, i.e. the strong and the electroweak 
sector, are represented by the classes Spectruin_EW and Spectruin_QCD. Both have only 
the method Fill_Masses() in order to set or calculate the masses of the different 
particles, when called. However, within the Standard Model, all fermion masses are 
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fundamental parameters, therefore, they are only read in from the Const . dat data 
file and set with the method Flavour: :set_mass(), shadowing the values given in 
Particle.dat. 

In contrast, the masses of the Z and W bosons are generated via spontaneous 
symmetry breaking and can be calculated to leading order, i.e. without quantum 
corrections, with the help of the coupling constants ckqed and sin Q-[^ and the Higgs 
vacuum expectation value (vev). In AMEGIC++, an option is provided to calculate 
these masses and set them, thus overwriting their values given in Particle.dat. 

Note that in the framework of the Standard Model, these classes seem somewhat 
over-engineered, but for later extensions to models beyond the Standard Model spec- 
tra should be calculable in dependence to some set of parameters which might or 
might not be different from the sheer listing of particle masses. As an example take 
the Minimal Supersymmetric Standard Model, where - neglecting quantum correc- 
tions - the masses of the partner particles in general depend on the mass parameters 
of the Standard Model particles plus some symmetry breaking terms. 

4.2.5 The Couplings 

Couplings_EW reads in the electroweak coupling constants and maintains the calcu- 
lation for the running of Oqed: 

1. Init reads in the coupling constants of the electroweak model, i.e. ckqed and 
sin^^y at the Z pole, the Higgs vacuum expectation value and the four pa- 
rameters of Wolfenstcin's parameterization of the CKM matrix. Accordingly, 
these values are set and the CKM matrix is generated. In order to calcu- 
late the running of q;qed all thresholds are determined with Thresholds (). 
Then, the coupling constant as well as the /^-function of the leading order run- 
ning which depends on the number of active charged fermions is calculated via 
Init_AQED(). 

2. Thresholds () determines all particle thresholds which contribute to the run- 
ning of ctQED, i-e. they have to have an electric charge. 

3. Init_AQED() determines ckqed at the scales introduced by the different particle 
thresholds. In order to obtain an efficient evaluation of the running coupling 
constant, the /3-function is precalculated as well. 

4. aqedO returns q;qed at a given scale. 

5. VEV() returns the Higgs vacuum expectation value. 

6. SinThetaWO returns the sin 

7. CosThetaWO returns the cos ^w^. 
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8. CKM() returns the specified entry of tlie CKM matrix. 

Note tfiat tfie running of electroweak parameters other than ckqed has not been 
implemented so far. Couplings_QCD reads in the strong couphng ckqcd and calculates 
its running: 

1. InitO reads in the only coupling constant of the strong interaction, oqcd at 
the Z pole. Similarly to the procedure in Couplings_EW the thresholds as well 
as the coupling constants at these thresholds are determined using the methods 
Thresholds () and Init_As(), respectively. 

2. Thresholds () specifies the thresholds for all strong interacting particles. 

3. Init_As() calculates the value of the strong coupling at the different threshold 
scales as well as the /3-function in order to perform a one loop running of the 
coupling. 

4. as2() returns ccqcd at a given scale. 
4.3 The Amplitude 

In this section we describe the generation of Feynman diagrams, their translation into 
the helicity amplitudes and their calculation. Accordingly, we start with the basic 
handling of amplitudes in Sec. 4.3.1, then dwell on the generation of the Feynman 
diagrams in Sec. 4.3.2 and on their representation within a Single_Amplitude in 
Sec. 4.3.3. In this section the translation into helicity amplitudes is performed as 
well. We end with the description of the tools for the calculation of the amphtude 
in Sec. 4.3.4 as well as the Color structure and Coulomb factors in Sec. 4.3.5. A 
short outline of the involved classes and structures can be found in Tab. 10, whereas 
a pictorial overview is given in Fig. 16. 

4.3.1 Handling of Amplitudes 

The organization of the generation as well as the calculation of a Feynman amplitude 
is governed by the class Amplitude_Handler: 

1. The Constructor governs the whole initialization procedure, i.e. the genera- 
tion of Feynman diagrams and their translation into helicity amplitudes in the 
following way: 

• All Feynman diagrams are generated with the construction of an 

Amplitude_Generator object and the call to its method MatchingO. 
This method constructs a list of Single_Ainplitudes, each of them rep- 
resenting an individual Feynman diagram through a list of linked - and 
filled - Points. 
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Class/Struct 


Purpose 


Amplitude_Handler 
Amplitude_Generator 
struct Pre_Amplitude 


Handles all amplitudes, i.e. the sum of all Feynman 
diagrams. 

Generates all amplitudes, i.e. matches the vertices 
onto the topologies. 
Is a Point list. 


Smgle_Amplitude 
Zf unc -Generator 

Zfunc 

Prop_Generator 
Pfunc 

Color .Generator 
Cfunc 


Handles one Amplitude, i.e. Feynman diagram. 
Translates the Feynman diagrams into 
helicity amplitudes. 

Is a structure for storing one Z-function. 
Finds and labels all propagators. 
Is a structure for storing one propagator. 
Determines the color structure. 

Is a structure for storing one color matrix. 


Building_Blocks 
MathematicaJnterface 

Composite_Zfuncs 
Elementary _Zfuncs 

Basic_Sfuncs 
Momfunc 


The different building blocks of a helicity amplitude. 

Interfaces to Mathematica, calculating some 

building blocks. 

Composed helicity amplitudes. 

All elementary helicity amplitudes, 

i.e. Z, X- and Y functions. 

The S functions. 

Is a structure which stores a four-momentum for 
incoming and outgoing particles as well as 
for propagators. 


Color 
Coulomb 


Calulates the sum of color matrices. 

Calculates Coulomb corrections for ly-pair creation. 



Table 10: All classes and structures which are used for the determination and calculation 
of a Feynman amplitude. 



• A loop over all amplitudes transforms them into the helicity amplitudes 
with Single_Amplitude : :Zprojecting(). The couplings are filled into 
the String_Handler by Single_Amplitude : :Fill_Coupling(). 

• Now, the dummy numbers for the polarization vectors can be replaced by 
the proper number within the Z-functions by calling 
Polarization: :Replace_Number(). 

• All the S-, Tj- and //-functions depending on the four-momenta, including 
the propagators, are calculated within Basic_Sf uncs. Having at hand all 
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Z-functions and the list of propagators Pf unc, they can be initiahzed with 
Basic_Sf uncs : :Build_Momlist(). 

• Last but not least the matrix composed of colour factors for each pair of 
amplitudes is calculated by constructing the Color object. 

2. Get_Graph() returns the Point list of a Feynman diagram for a given number. 

3. Fill_Coupling() performs a loop over all Single_Amplitudes and fills the 
couplings into the String_Handler via Single_Amplitude : : Fill_Coupling() . 

4. Get_Graph_Number() returns the number of graphs. 

5. Get_Pointlist () returns the Point list of a Feynman diagram for a given 
number. Note that this method considers the full list of graphs, not the short- 
ened version of the Single_Amplitude list, where some graphs are united which 
differ only by a photon, Z or Higgs boson propagator. 

6. Get_PointlistNumber() returns the number of the full Point list. 

7. dif f erential (int* , int) calculates the differential cross section by using the 
standard calculation methods, i.e. no character strings. The arguments of the 
method are a list of signs for the different helicities of incoming and outgoing 
particles, whereas the second argument corresponds to the counting number 
of the current helicity combination. A loop over all amplitudes and a call 
to Single_Amplitude : :Zvalue() fills the complex value of one diagram for a 
specific helicity combination into an array. At the end, taking into account 
the elements of the color matrix (Color: :Mij()), all diagrams are summed 
up. Sometimes, single diagrams yield zero depending on the structure of the 
couplings. This is taken care of by storing the value of each diagram and 
dropping those which yield no result at all after a user defined number of calls, 
typically one thousand. 

8. The second dif f erential (int) method differs from the other one by two 
points. First, the amplitude is calculated using the already generated character 
strings for the evaluation of each diagram via String_Handler : :Zvalue(). 
Accordingly, only one argument is needed for this method, i.e. the current 
counting number of the helicity combination. Second, since these character 
strings are already shortened, i.e. zero parts are dropped, no special care has 
to be taken for zero diagrams. 
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initialize 
employ 



Amplitude_Handler 

Amplitude_Handler(Flavour*,Polarisation*,Vertex* 
Topology*,Basic_Sfuncs*, 
String_Handler*) 

Differential 



Color 



Color(Single_AmpIitude*,string&) 
» ReplaceT 
=- ReplaceD 
- ReplaceF 
» Single_ReplaceF 
=- Single_ReplaceFT 



employ 



String_Tree 



employ 



employ 



Single_Amplitude 



Amplitude_Generator 



Single_Amplitude* MatchingO 

Set_End(Point*,int) 
Set_Props(Point*,Single_Amplitude*) 
o- Clieck_End(Point*, Vertex*) 

Match_Vertex(Single_Vertex,Flavour*) 
=. Next_P(Point*,Point* &) 
Compare(Single_Amplitude*) 

Single_Compare(Point*,Point*) 
— E- SimpIify(SingIe_Amplitude*) 
Unite(Point*,Point*) 
Single_Topology* 
Pre_Amplitude* 
Vertex* 



4.3.2 Generating the Feynman diagrams - Amplitude_Generator 

The structure Pre_Amplitude stores a hst of points. Therefore it can be regarded 
as a predecessor of a proper Single_Amplitude. In fact, until this Pre_Amplitude 
has not passed certain tests it cannot become a full amplitude. The generation of 
these Pre_Amplitudes as well as the handling of the full amplitudes is governed by 
the class Amplitude_Generator by means of the following methods: 

1. The Constructor obtains the topology which fits the actual number of legs 
via Topology: :Get() and generates an empty list of Pre_Amplitudes. 

2. MatchingO is the main method within this class. It constructs the hst of 
Single_Amplitudes and simplifies them. For the first step all permutations 
of the incoming and outgoing particles are constructed. This is achieved by 
a loop over loops technique (cf. Appendix C), where the permutations are 
generated and then have to obey certain constraints, listed in Sec. 3.1. Hav- 
ing passed these constraints a permutation of incoming and outgoing parti- 
cles can be matched on all possible topologies. First of all, these particles 
are set to the endpoints of a certain topology with Set_End(). After this, 
all possible propagators in between are tested with Set_Props() and even- 
tually diagrams are generated. At the very end of the loop over loops all 
diagrams are stored into a list of Single_Amplitudes. However, similar di- 
agrams could still occur and have to be dropped. This is achieved with the 
method Compare (). Having at hand the full list of distinguishable diagrams, 
they are stored (Save_Pointlist()) for the later use in the construction of 
Channels employed during phase space integration. Now the list of diagrams 
can be shortened by unifying those which differ only in a photon, Z or Higgs 
boson propagator with the method Simplify (). 

3. Set_End() recursively sets all endpoints of a topology onto a particle permuta- 
tion, i.e. the particle number, its flavour and the b flag which marks incoming 
and outgoing particles. Propagators are labeled with numbers beginning with 
100. 

4. Set_Props performs the matching procedure for one topology and one combi- 
nation of endpoints. Basically, it tries to find every possible flavour combination 
for the inner propagators in the following way: 

At first, the raw topology with the endpoints already set is copied into a 
Pre_Amplitude. Then a loop over all Pre_Amplitudes is performed. Within 
the loop, every time, an internal line is equipped with a flavour, i.e. each time 
a new propagator is tested, a new Pre_Amplitude is created and appended. 
Consequently, the loop over Pre_Amplitudes ends, if no more propagators can 
be tested. The test is performed along the following steps: 
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• The next free propagator in the actual Pre_Amplitude, i.e. a Point where 
the flavour is not set already, is selected via Next_P(). If no free Point 
can be found, the loop advances to the next Pre_Amplitude. 

• A loop over all possible vertices is performed. Each vertex is compared 
with a flavour combination which is manipulated in the way described in 
Sec. 3.1. This is done with Match_Vertex() . 

• If the comparison was successful, the flavours of the outgoing particles are 
set onto this vertex. If they are connected with endpoints, the left and 
the right Points are checked by (Check_End()). 

• Having passed all these tests, the actual Pre_Amplitude is copied. It is 
attached at the end of the list of Pre_Amplitudes and the appropriate 
vertex is changed in the copy. This method ensures that all other vertices 
can be tested as well for this particular Point. 

• If the loop over the vertices has finished, the loop over the Pre_Aniplitudes 
proceeds to the next amplitude and the actual one is switched off. There- 
fore, every new Point which has matched onto a vertex, yields a new 
amplitude. In this way, only amplitudes which are fully filled, reach the 
end of the loop. If no new amplitude exists, the loop terminates. 

In this fashion, a number of pre-amplitudes has been generated which will be 
subjected to some simple tests in order to avoid double counting of Feynman 
diagrams: 

• If the chosen model is QCD (all QCD Feynman rules plus a coupling 
to electrons and positrons), only diagrams can survive which have just 
one electroweak (i.e. photon, Z boson) propagator. This is used for the 
generation of QCD final states in electron-positron annihilations. 

• In multiple boson vertices a certain ordering of the particles has to be 
demanded in order to avoid a double counting of, for instance, three gluon 
vertices. 

Passing these tests the located Pre_Amplitude can be translated into a proper 
Feynman diagram, i.e. a Single_Amplitude. An additional minus sign for 
every exchange of two fermions is included and stored as well. 

5. Next_P() searches recursively through the list of Points for the next undeter- 
mined propagator, i.e. for a Point with the Flavour not yet set. 

6. Print _P() prints a Point list recursively. 

7. In Match_Vertex() a given combination of Flavours is compared with a given 
Single_Vertex, i.e. all Flavours which are set will be compared and if they 
match, the unset Flavours as well as the coupling constants can be filled. 
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8. Check_End() checks for a given Point with already set flavour whether the 
linked left and right Points are already endpoints and, if this is the case, 
whether they match. For the matching part, a loop over all possible vertices 
is performed and every vertex is compared with a slightly modified flavour 
combination of the incoming and the two outgoing particles. The flavours are 
changed according to the rules presented in Sec. 3.1. Having at hand the proper 
flavour combination it is checked against the actual vertex via Match_Vertex(). 
If the checks are passed, the couplings of the Point are set. 

9. Compare () performs a comparison of all amplitudes. Since the derived list of 
Feynman diagrams could still have some double countings, this step is neces- 
sary. Within a double loop over all Single_Amplitudes the appropriate Point 
lists are compared with Single_Compare(), where one of them is marked for 
deletion in case they are equal. This is achieved by using the On switch of 
a Single_Ainplitude. Finally, all marked amplitudes are deleted with the 
method Kill_Off (). 

10. Single_Compcire() compares two Point lists recursively which means that in 
one recursion step always two Points are inspected. They are checked for equal 
Flavour and number. After this, the left and right Points are compared with 
a recursive call to Single_Coinpare () . However, if the regarded Point belongs 
to a triple gluon vertex, the left and right branch could be exchanged and 
compared again. Thus, all possible combinations of exchanging the different 
branches are considered. 

11. Kill_Off deletes all marked Single_Amplitudes which arc switched off. A 
loop over all possible amplitudes and an appropriate reordering of the list of 
Single_Amplitudes is sufficient for this purpose. 

12. Save_Pointlist() saves all Single_Amplitudes into a list of Point lists. This 
is necessary for the later use within the Channel_Generator for the phase space 
integration. 

13. Simplify () compares all different amplitudes. If two of them differ only by 
a photon, Z or Higgs boson propagator they can be united and regarded as 
the same amplitude. Later on, during the calculation of the different pieces 
of helicity amplitudes, the contribTitions of the different propagators will be 
summed up. Therefore, always two Point lists are compared. In case they 
differ only be the regarded boson propagators, they are unified with the method 
Unite (). 

14. Unite unites two amplitudes which differ only by a photon, Z or Higgs boson 
propagator. Therefore, the arrays of couplings for the start and end Points of 
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Figure 17: One Feynman diagram. 



the propagator have to be enhanced to include the appropriate coupling of the 
other propagator types. The Flavour of the propagator is exchanged with a 
list of Flavours for all occurring flavour types. 

4.3.3 A single amplitude 

The Single_Amplitude is an implementation of a particular Feynman diagram. 
Therefore, it includes the Point list for the graph, a list of Zfuncs for the trans- 
lation of the graph into helicity amplitudes, a list of propagators and a list of color 
matrices. The class governs the generation of all these lists and calculates the am- 
plitude with the help of Building_Blocks, for a pictorial overview of the connection 
to other classes see Fig. 17. Furthermore, Single_Amplitude provides a number of 
methods for manipulating the generated lists. 

1. The Constructor initializes the list of Points. However, during the gener- 
ation of this list in the Amplitude_Generator not much care has been taken 
to the correct direction of the spin flow for the first fermion line. There- 
fore, a number of propagators might still have the wrong spinor direction. 
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i.e. they are considered to be particles instead of anti-particles or vice versa. 
In order to cure this problem, two methods (lnitial_Fermionline() and 
Reverse-FermionlineO) are used in the following way: 

• If the first particle is an incoming fermion and not an anti-particle, the 
initial spinor line is marked with Initial_Fermionline(). Furthermore, 
the endpoint of this line is determined as well. 

• If the endpoint of this fermion line is an outgoing particle, the spin flow 
of this first spinor line is reversed beginning with the last particle in 
Reverse_Fermionline ( ) . 

During these two steps a special flag in the Point list (t) is set. Later on, during 
the generation of the list of propagators, this flag determines the particle or 
anti-particle character of the appropriate propagator. 

2. Initial-FermionlineO determines recursively the initial fermion (i.e. spinor) 
line and its endpoint. The pointer to the previous Point is set as well. 

3. Reverse_Ferniionline() starts from the endpoint of the first fermion line. The 
t flag is set equal to one in case the propagator is an anti-particle. 

4. ZprojectingO translates the Feynman diagram into the helicity amplitude 
language in the following steps: 

• The colour structure of the Feynman diagram is determined using the 
Color_Generator. With Color .Generator: : Convert () every vertex gains 
a colour matrix and Color .Generator: :C2string() translates the whole 
term into a character string which will be used for later evaluation. 

• The various pieces of a helicity amplitude are generated within the 
Zfunc_Generator. Therefore, Zf unc_Generator : : Convert () interprets 
the Feynman diagram, i.e. the list of Points in terms of helicity amplitudes 
and Zf unc_Generator : :Flip() changes the sequence of pairs of barred 
and unbarred spinors, so that in each pair, barred spinors come before 
unbarred ones in accordance with the deflnition of the Y- and Z- 
functions. 

• The Prop_Generator constructs a list of propagators, i.e. determines the 
momenta of the different propagators in terms of incoming and outgo- 
ing particles. With Prop_Generator : : Convert () the list is generated, 
Prop_Generator : :Fill() fills in the ingredients (dependencies on exter- 
nal particles) of every propagator and kills the ones which are not used 
(Prop_Generator : :Kill()). In this method, the list of Zfuncs is explored 
and every propagator which could not be found, is deleted. 
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Now, lists of Zf uncs, Cf uncs and Pf uncs for the helicity amplitudes, the color 
matrices and the list of propagators, respectively, are at hand. 

5. Fill_Coupling() fills all couplings into the String_Handler. For this purpose, 
a loop over all Zfuncs is performed and every particular coupling is set via 
String_Handler: : Get_Cnumber() . 

6. MPolconvert converts polarizations, i.e. replaces every number in the list of 
Zfuncs with a given new number for the polarization. 

7. Prop_Replace() adds a new propagator to the list of Pfuncs. This method 
is commonly used for massive polarization vectors, where an external massive 
vector boson is treated like a propagator decaying into its polarizations. 

8. ZvalueO calculates the helicity amplitude for one Feynman diagram ^: 

• The maximum number of fermionic propagators (i.e. those which are 
switched on) is determined and their numbers are stored into an array. 

• If this number of propagators equals zero, only one Zfunc has to be cal- 
culated. The arguments of the Z function as well as their helicities are 
filled into a list of arguments via Fill_Args(). Then, the appropriate 
couplings are set via Building_Blocks : :Set_Arg_Couplings(). Now the 
Z function can be calculated with Single_Zvalue() . 

• If any fermionic propagator exists, a loop over all possible states for every 
fermion propagator has to be performed. Since the number of propagators 
is not known in advance, a loop over loops technique has to be applied 
(cf. Appendix C). In the external loop the sign of the propagators which 
correspond to a particle or anti-particle state, and the two helicity states 
have to be altered. Having at hand one such sample, the product of all 
Z functions for this amplitude has to be calculated using a loop over 
all Zfuncs. The evaluation is performed in the same way as described 
above for a single Zfunc. Now, the product of all Z's is multiplied with 
an extra mass term (Mass_Terms()) which corresponds to the real and 
virtual propagator mass, see Eq. (2.13). The contributions for every set 
of propagator states is summed up and multiplied at the very end with 
all emerging fermion propagators (Building_Blocks : :Set_P()) and with 
a factor of one half taking into account the sum over particles and anti- 
particles. 

Finally, the calculated value multiphed by the overall sign of the amplitude is 
returned. 

^Note, that by construction, the boson propagators are already part of the Z-function. 
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9. Fill_Args() constructs the list of arguments for one Z function. For this 
purpose it uses the hst of hehcities for the incoming and outgoing particles as 
well as the list of propagators with their appropriate helicity states. A loop over 
the arguments of the Z function is performed and translated in the following 
way: 

• If the argument is a propagator, i.e. the number is larger than 99, a 
signed propagator number and the appropriate helicity is added to the 
list of arguments. The sign corresponds to a particle or an anti-particle 
state propagating. 

• If the argument is an incoming or outgoing particle, its number and he- 
licity are taken over unchanged. 

• If the argument corresponds to a polarisation of a massless vector boson, 
its number is larger then the maximum number of particles and smaller 
than 20. In this case, the hehcity of the polarisation is the same as the 
helicity of the appropriate massless vector boson and the number of the 
momentum is translated via subtracting 10. 

• The number of the polarisation for a massive vector boson is always be- 
tween 20 and 99. These polarisations get a hehcity of minus one by con- 
struction and the momentum number can be gained by subtracting 20. 

10. Single_Zvalue() calculates one Zfunc using the various possibilities of the 
Building_Blocks. 

11. Mass_Terins calculates the mass term of Eq. (2.13) for the decomposition of 
fermionic propagators using Building_Blocks : :Set_Mass(). 

12. printgraphO prints all lists for one Feynman diagram, i.e. the list of Zfuncs, 
Pf uncs and Cf uncs. 

13. Get_Pointlist () returns the list of Points. 

14. Get_Clist() returns the list of colour matrices, i.e. Cfuncs. 

15. Get_Plist() returns the list of propagators, i.e. Pfuncs. 

The structure Zfunc includes all informations which are necessary to calculate an 
arbitrary Z function, namely the type (— 1..9), the list of arguments and the list of 
couphngs, see Tab. 11. Last but not least every bosonic propagator which is involved 
in this Z function is stored as well in a special list. This will become necessary later 
on for the calculation of massive vector boson propagators. 

The class Zfunc_Generator constructs the list of Zfuncs, i.e. it translates a 
Feynman diagram into the helicity language by decomposing it into a number of 
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Type 


#arg 


#coupl 


#prop 


Description 


-1 


2 


2 





A scalar boson which is connected 










to two fermions. 





4 


12 





An outgoing or incoming vector boson 










attached at a fermion hne 








1 


or two fermion hnes connected via 










a vector boson. 


1 


6 


10 


3 


A three vector boson vertex. 


2 


6 


7 


3 


A two vector and one scalar boson vertex. 


3 


6 


10 


3 


A one vector and two scalar boson vertex. 


4 





1 





A three scalar boson vertex. 


5 


8 


10 


5 


The four vector boson vertex. 


9 


10 


13 


7 


The five vector boson vertex. 



Table 11: All possible types of a Zfunc and their description as well as the number of 
arguments, couplings and propagators. 



Particle type 


Number 


Incoming or outgoing 


0-9 




Fermion propagator 


100-120 




Boson propagator 


200- 




Polarization of a massless vector boson 


Number of the boson plus 


10. 


Polarization of a massive vector boson 


Number of the boson plus 


20. 


Dummy numbers for the calculation 


120-140 




of the Color matrices 







Table 12: The particle numbering scheme in the list of arguments for every Z function. 

Z functions. This is one of the central parts of the program. Note that during 
the determination of the list of arguments for every Z function, a certain internal 
numbering scheme is applied, for details see Tab. 12. 

1. Convert () translates a given graph, i.e. a list of Points into the list of Zfuncs 
recursively. A new Zfunc will be produced, if the current particle is a fermion, 
a scalar boson or an incoming vector boson. Depending on the Flavour type 
of this particle, two pointers will be set. In case it is a fermion, one pointer 
is set to the outgoing boson and one to the outgoing fermion. If the particle 



66 



is a boson, only the boson pointer is set, whereas the fermion pointer is set to 
zero. With the current Point and these two pointers as arguments the type of 
the Zfunc can be determined (Determine_Zfunc()) and the arguments can be 
filled in (Fill_Zf unc ()). At the end two recursive calls to Convert () , with the 
left and the right hand Point as arguments, ensure the recursive examination 
of the whole graph. 

2. Determine_Zfunc() determines the type of the Zfunc according to Tab. 11, 
where the method IsGaugeVO is used to count the number of vector and scalar 
bosons at one vertex. 

3. IsGaugeVO determines the number of vector and scalar bosons within one 
vertex. 

4. Fill_Zfunc() specifies all arguments, couplings and propagators of one Zfunc. 
First of all, the sizes of all three lists are determined (see Tab. 11). Now, the 
different lists can be initialized and filled by calling the appropriate method. 
Note that each type of Zfunc has its own method (Zml(), ZOO, etc.). 

5. Set_In() sets the arguments and couplings for the incoming part of a Zfunc. 
If the fermionic pointer is set (see Convert O), the arguments are set on the 

current and the fermionic pointer, where the sequence is always anti-particles 
before particles. The two couplings will be filled with the couplings from the 
current pointer. Note that the sign of the graph gains an extra minus for a 
fermionic anti-particle propagator. The second case is addressed to an incoming 
boson. If it is scalar, both arguments are set on the number of this boson and 
the couplings are set to zero (this is only the dummy part of a Zfunc). For 
a vector boson the first argument is set on the number of the boson and the 
second is set to the number plus 20 or 11 for massive or massless vector bosons, 
respectively. Here, the couplings are set to unity. 

6. Set_Out() sets the arguments, couplings and propagators for one outgoing end 
of a Zfunc. At the beginning, the propagator will be set onto the current boson. 
If the boson is not an outgoing one the arguments of the Zfunc are set onto 
the numbers of the left and right hand particle. The sign of the graph will be 
changed for a fermionic propagator on the left hand side (i.e. an anti-particle 
propagator). Outgoing bosons will be managed in the same way like incoming 
bosons (see Set_InO), but with an reversed sequence of arguments. 

7. Set_Scalar() sets the left- and right-handed couplings to a scalar boson 
within a Zfunc. This means that both arguments are set to the number of 
the scalar boson and the couphngs are set to zero. The fist of propagators is 
enhanced by the scalar boson propagator. 
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8. Get_Flav_Pos3 determines the position of the three electroweak vector bosons 
in the method Zl(). 

9. ZmlO sets the arguments with Set_In() or Set_Out() for an incoming or 
outgoing scalar boson, respectively. 

10. ZO specifies the arguments and couplings for a vector boson exchange between 
two fermion lines or an incoming or outgoing boson: 

• For an incoming or outgoing scalar boson the incoming part will be set on 
position (Set_In()) and the outgoing part at position 1 (Set_Out()). 

• The same holds true for an incoming vector boson. 

• In the case of outgoing vector bosons or the exchange of a vector boson 
between two fermion lines the outgoing part is set on position and the 
incomings are set on position 1 with Set_Out() and Set_In(), respec- 
tively. 

Note that the sequence of the arguments plays an important role during the 
calculation of the Z function. However, multiple propagators (7, Z, Higgs- 
boson) will be considered by enhancing the list of couplings of the Zf unc. 

11. The methods Z{1,2,3,4}() correspond to a three boson vertex, where the 
positions within the list of arguments depend on the appropriate vertex, for 
details see Tab. 13. Note that all incoming bosons are placed with Set_In(), 
outgoing bosons are set with Set_Out() or Set_Scalar() for vector or scalar 
bosons, respectively. However, multiple propagators can occur in the case of 
vector bosons, too. Then, the list of couplings will be enhanced by the extra 
couplings. 

12. Z5() sets the arguments for the four vector boson vertex, see Tab. 14. Apart 
from that, all other options are the same like in the three boson vertex case. 

13. Z9() considers the calculation of the five vector boson vertex. Note that in the 
current version only the five gluon vertex is used, i.e. no five electroweak gauge 
boson vertices are taken implemented yet. This is part of future work. 

14. FlipO takes care for the correct order of particle and anti-particles in the list 
of arguments in the Zfuncs, i.e. the sequence of spinors. Here, anti-spinors 
always have to stand before spinors in the appropriate two-particle blocks of 
the Zfuncs. Therefore a loop over all Zfuncs is performed and the arguments 
of every function are examined. Now, a change will occur in case an incoming 
fermion or an outgoing anti-fermion is placed before its partner. The same 
change will be enforced, if the second particle is an incoming anti-fermion or 
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Method 


Incoming 


Left 


Right 


Condition 


zio 


2 





1 


For a three gluon vertex. 




2 





1 


For 7/Z, W, W vertex. 







2 


1 


For W^,7/Z,M^ vertex. 







1 


2 


For ly, VT, 7/^ vertex. 


Z2() 


2 





1 


For H, Z/W, Z/W vertex. 







2 


1 


For Z/W, H, Z/W vertex. 







1 


2 


For Z/W, Z/W, H vertex. 


Z3() 


2 





1 


For V, S, S vertex. 







2 


1 


For S, V, S vertex. 




1 





2 


For S, S, V vertex. 


Z4() 








For S, S, S vertex (is only a couphng) . 



Table 13: The positions in the hst of arguments for the different three boson vertex types 
and consteUations. 



Method 


I 


L 


LL 


LR 


R 


RL 


RR 


Condition 


Z5() 







3 


2 


1 






For 7/Z; W- -i/Z; W vertex. 




1 




3 





2 






For W; W; 7/Z; 7/Z vertex. 







1 








2 


3 


For 7/Z; W; 7/Z; W vertex. 




1 











2 


3 


For W; 7/Z; 7/Z; W vertex. 







1 








2 


3 


For G; G; G; G vertex. 



Table 14: The positions in the hst of arguments for the four vector boson vertex with 
different constellations. Note that / stands for incoming, L and R for left and right, 
respectively. 

an outgoing fermion. Both checks are necessary, since one of the arguments 
could be a propagator, where the spinor or anti-spinor property is not fixed 
before. If a change should be performed and the partner of the examined 
particle is a propagator, not only the current Zf unc but also a second one will 
be altered. This is due to the fact that a fermionic propagator always emerges 
in two Zf uncs. Now, if the propagator stands on the first position after the 
change, the second occurrence of the propagator in another Zf unc has to be as 
a second argument. Therefore, the other Zfunc will be searched and changed 
accordingly. However, this second occurrence of the propagator can have a 
propagator as a partner as well. Consequently, the change of the position for 
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this partner results in another change for its second appearance and so on. In 
this way, the whole fermion line will be flipped. 



15. GetO returns the hst of Zfuncs. 

The structure Pfunc contains all informations to characterize a propagator. The 
necessary arguments are the number of the propagator and all those incoming and 
outgoing momenta which sum up to its momentum. A Flavour gives the type of the 
propagator and a complex number stores the calculated value. Last but not least an 
on switch allows the dropping of individual propagators. 

The class Prop_Generator generates the list of propagators, i.e. the Pf uncs, and 
calculates their complex value for one individual graph: 

1. Convert translates a topology, i.e. a list of Points into a list of propagators 
(Pfuncs). A propagator is characterized through a number which is larger than 
99 (this corresponds directly to our numbering scheme, see Tab. 12). Now, a re- 
cursive examination of the whole tree yields all possible propagators. Note that 
some of the propagators are combined for different boson types (i.e. photon, Z, 
and Higgs boson). Since different boson types yield different propagator values, 
a new propagator will be generated for every boson. For every propagator a 
Pfunc is created and attached to the list. The first argument of the Pfunc is 
the number of the appropriate propagator and the two next arguments corre- 
spond to the numbers of the left and right handed particles in the graph. At 
the end of the method two recursive calls to Convert () will be performed. 

2. FillO completes the list of arguments for the propagators. In Convert () 

every propagator is filled into a Pfunc. The arguments of this Pfunc are the 
fiavour of the propagator and the left and right handed particles. However, in 
order to calculate the four-momenta of the propagators later on, the dependence 
on the incoming and outgoing particles is needed (since only the four-momenta 
of these particles are available). The task of this method is to replace the 
dependence of the propagator on the left and right handed particle by the 
dependence on all (incoming and outgoing) particles which are attached at the 
same branch. Therefore, a loop over all Pfuncs is enclosed by a loop which 
ends, when all dependencies are filled in. Now, every Pfunc is examined. If a 
propagator is found in the arguments, the number of this propagator is replaced 
by the list of dependencies for this propagator itself. These replacements are 
performed until every propagator has a list of dependencies which includes only 
the numbers of incoming and outgoing particles. 

3. KillO deletes all propagators which do not appear as an argument in the list 
of Zfuncs. A loop over all propagators and Z functions searches for the number 
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of the current propagator in the hst of arguments of the current Z function. If 
a propagator could not be found, it will be switched off. 

4. Calculate () evaluates the complex value of all propagators. Consequently, 
a loop over the list of Pf uncs is performed. Within the loop first of all, the 
four-momentum of the current propagator has to be determined. This can be 
achieved by adding up all the depending four-momenta of incoming and out- 
going particles, i.e. all four-momenta which are attached at the same branch 
of the tree as the propagator. Note that the four-momenta of the incoming 
particles are multiplied with a —1. Now, the complex value of the propagator 
can be calculated using the mass and the width of the current particle. Ac- 
cording to our Feynman rule conventions every fermionic and scalar particle is 
multiplied with an extra complex unit and the vector bosons are provided with 
minus a complex unit. 

5. GetO returns the hst of Pfuncs. 

The structure Cfunc represents an clement of the color matrices, i.e. a generator of 
the SU{i) color group (T^") or a structure constant of the group (fabc)- They are 
indicated by different types within Cfunc, where a 10 represents a delta function, a 
corresponds to a generator of the fundamental representation and the number 1 is 
connected with a structure constant. The appropriate labels (abc) are saved in a list 
of arguments. 

The Color_Generator generates a list of these Cfuncs which belong to every 
graph. A string representation will be created as well, in order to simplify the 
calculation of the color factors later on: 

1. Convert () generates the list of Cfuncs. Therefore, the whole topology of a 
graph is searched recursively and every vertex yields a new color matrix Cfunc 
depending on the incoming and the two outgoing particles of this vertex (see 
Tab. 15). At the end two recursive calls to Convert () (with the left and right 
hand side Point) ensure that every vertex in the topology is translated into a 
Cfunc. 

2. KillO performes a first simplification of the color structure, i.e. all delta func- 
tions which involve propagators, are deleted and the appropriate replacements 
are done within the list of Cfuncs. Accordingly, a loop over all Cfuncs is per- 
formed and every delta function (i.e. type equals 10) is examined. If one of the 
two arguments is a propagator, all emerging numbers of this propagator will 
be replaced by the second argument in all Cfuncs. At the end these Cfuncs 
which correspond to a delta function with propagator indices only, are deleted. 
Note that delta functions remain which have incoming or outgoing particles in 
the argument. 
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Incoming 


Left 


Right 


Type 


argO 


argl 


arg2 


Condition 




outgoing 


outgoing 












Quark 


Boson 


Quark 


0/10 


L 


R 


I 


Incoming anti-quark. 










L 


I 


R 


Incoming quark. 


Quark 


Quark 


Boson 


0/10 


R 


L 


I 


Incoming anti-quark. 










R 


I 


L 


Incoming quark. 


Boson 


Quark 


Quark 


0/10 


I 


L 


R 




Boson 


Boson 


Boson 


1 


I 


L 


R 





Table 15: In this table the different alloeations for the arguments of a Cfunc are shown. 
The left, right and the incoming particle are denoted as L, R, and I, respectively. Note 
that the type depends on the nature of the boson. In case it is a gluon, the type is and 
for all other bosons the type is 10. 



3. C2string() translates the list of Cfuncs into a character string. During the 
generation of the string, every type of Cfunc will be translated accordingly, 
i.e. type into a T[A, b, c], type 1 into a F[A, B, C] and type 10 into a D[a, b] 
function. Note that every upper case letter lies in the range of 1 ... 8 and the 
lower case letters in the range of 1 ... 3. Furthermore, some care has to be 
taken that propagators which appear in different Cfuncs, gain the same letter. 
However, at this stage not only the color string will be created, but also its 
complex conjugate. Here, every propagator has to get a totally new letter with 
respect to the propagators in the original string, since these letters are only 
inner summation indices. Consequently, the color factor can now be calculated 
by just merging those two strings and no special care has to be taken for inner 
summation indices any more. This simplifies the calculation significantly later 
on (see the class Color). 

4. GetO returns the hst of Cfuncs. 
4.3.4 Calculating the Amplitude 

The calculation of the amplitudes is organized on different abstraction levels. On the 
highest level stands the class Building_Blocks which evaluates the different com- 
posed Z functions and will be called from within Single_Amplitude. The building 
blocks themselves rely on the Composite_Zf uncs and the Mathematica_Interf aces, 
where the latter one uses the methods of the Composite_Zfuncs as well. Strictly 
speaking, these composed Z functions translate a simple notation of the differ- 
ent Z functions into a call with all arguments, where the methods of the class 
Elementary_Zf uncs will be used. These methods calculate all the Z,X,Y, etc. func- 
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tions with the help of a set of basic spinor products and normahzations which are 
estabhshed in the class Basic_Sf uncs. This is the lowest level class which directly 
uses the four-momenta of the incoming and outgoing particles. 

The Building_Blocks are the basic elements of a calculation. They calculate 
one single Z function and are called from within Single_Ainplitude : :Zvalue(): 

1. With the Constructor of this class a new object of Composite_Zf uncs is 
initialized. Together with the Mathematica_Interf aces they form the basic 
calculational tools of this class. 

2. Reset resets the Composite_Zf uncs object (via the appropriate Reset () 
method). 

3. Set_Arg_Coupl() is used to set the list of arguments and couplings within this 
class and the Composite_Zfuncs object. 

4. Set_P() calls Composite_Zf uncs : :Set_P() and calculates the Kabbala value 
of the given propagator (Pf unc) . 

5. Set_Mass() calculates the mass term which occurs during the decomposition 
of the fermionic propagator into products of spinors (via 
Composite_Zfuncs : :Set_Mass()). 

6. Z2() calculates the Kabbala value of the original Z function. Here, the different 
contributions of multiple propagators (photon, Z and Higgs boson) are summed 
up as well. The Z function is calculated via Composite_Zf uncs : :Z_Z() and 
the propagator via Composite_Zfuncs: :Z_P(). Note that the contribution 
of a scalar boson exchange is composed of the product of two Y functions 
(Composite_Zfuncs : :Z_Y()). The last missing piece is the mass term which 
appears in the numerator of the propagator for massive vector boson ex- 
changes jM'^\ This term can be composed out of two X functions 
(Composite_Zf uncs : :Z_X()) and a constant which is directly handled using 
the method String_Generator() : :Get_Enumber(). Note that this method 
translates a complex number into a Kabbala object and saves the value in the 
list of Zfuncs (see Sec. 4.4). 

7. All other methods calculate an appropriate n boson vertex, usually with the 
help of a Mathematica_Interf ace(). A new object will be created the first 
time this method is called. The result is a product of the list of the inner 
propagators (gained via Composite_Zf uncs : :Z_P()), the value of the vertex 
(Mathematica_Interf aceO : : Calculate ()) and the coupling constant 
(String_Handler : :Get_Enumber()). A further complication can arise when 
multiple propagators occur (i.e. a photon and a Z boson). Then the contri- 
butions will be simply summed up. If more than three vector bosons appear 
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Method 


Purpose 


Z3V() 


Three vector boson vertex, 




sums up multiple propagators with Z31. 


Z31() 


Three vector boson vertex. 


ZVVS() 


Two vector, one scalar boson vertex. 


ZSSV() 


Two scalar, one vector boson vertex, 




sums up multiple propagators with ZSSVK). 


zssvio 


Two scalar, one vector boson vertex. 


ZSSS() 


Three scalar boson vertex, simply a coupling. 


Z4V() 


Four vector boson vertex. 


Z5V() 


Five vector boson vertex. 



Table 16: A selected list of methods for the calculation of an n boson vertex. 

in one vertex, a sum of the multiple iterated three vector boson vertices and a 
quadruple vector boson vertex has to be performed. This is due to our handling 
of quadruple vector boson vertices. However, a detailed list of every method 
can be found in Tab. 16. 

The Matheinatica_Interf ace can be used to implement algebraic expressions which 
are produced by Mathematica. Here, the output of the appropriate Mathematica 
session will be translated into a proper C++ file and linked to the object. This process 
can be done in a semi-automatic way. However, usually all necessary calculations 
have been already performed and the linked C++ files are ready to use: 

1. The Constructor () can be used with two different options. The first one which 
is the usual option, is used for the calculation of already translated methods. 
An identity string indicates the method to be used. In the second option a 
Mathematica file will be read in and translated into a C++ file. First of all, the 
file will be read in and casted into a string. The method Shorten () deletes all 
occurrences of p and q characters which are necessary in the Mathematica file, 
but are now obsolete. With C_Output() the string will now be translated into 
a C++ file. All other parts, i.e. the linkage of this new method and the calling 
sequence have to be included by hand, a sample could be found in Appendix B. 

2. C_Output transforms an algebraic expression in the form of a character string 
into a C++ method of this class. Therefore a new file will be created and the 
output of the string expression is performed in the same way as the output of 
the libraries, see Sec. 4.4, i.e. a maximum number of characters per line will be 
enforced. 
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Method 



vGGG() 

vZWWQ 

vWS() 

vSSV() 
vGGGGJtO 

vGGGG_q() 
vZZWWJtQ 
vZZWW_q() 
v5GJt() 

v5GJtq() 



Purpose 



Three vector boson vertex without any mass terms. 
Three vector boson vertex including all mass terms. 
Two vector one scalar boson vertex. 
Two scalar one vector boson vertex. 
Two iterated three boson vertices as a part of the 
four vector boson vertex, masses are neglected. 
Quadruple vector boson vertex, masses are neglected. 
Like vGGGG_it(), but including all mass terms. 
Like vGGGG_q(), but including all mass terms. 
Three iterated three boson vertices as part of the 
five vector boson vertex, masses are neglected. 
One triple plus one quadruple vector boson vertex, 
neglecting masses. 



Table 17: A selected list of methods for the direct calculation of a part of a multiple boson 
vertex. 



3. Shorten uses Kill_String() to delete all p and q characters 

4. Kill_String() kills the occurrence of a given character in a string. 

5. Calculate is the steering routine of the calculational part of this class. Ac- 
cording to the given string identity, this routine choses the appropriate method 
for the evaluation. 

6. The methods Z(), X(), S(), Y() and M() calculate an elementary Z, X, S, 
or Y function or a mass term, respectively. The appropriate methods Z_Z() , 
Z_X() , Z_S() , Z_Y() and Z_M() of the class Coinposite_Zfuncs are used ac- 
cordingly. 

7. All other methods calculate a multiple boson vertex directly, see Tab. 17. 

The class Coniposite_Zf uncs translates a simplified form of a call to the elementary 
Z functions (Elementary_Zf uncs) into a full calling sequence. Therefore this class 
mainly exists for a better readability of the Building_Blocks and the 
Mathematica_Interf ace: 

1. The Constructor () creates a new Elementary_Zf uncs object. 

2. Reset sets the pointers of the arguments and the couplings of a Z function 
to zero. 
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3. Set_Arg_Coupl() sets the arguments and couplings of a Z function. 

4. Set_P() calls the method Elementary_Zf uncs : :P() in order to calculate the 
value of a propagator. 

5. Set_Mass() calls the method Elementary_Zf uncs : :Mass_Term() in order to 
evaluate the extra mass term of a decomposed fermionic propagator, sec Eq. (2.13). 

6. Z_P() calculates the product of propagators for a Z function. Therefore, a list 
of propagator numbers is used to extract all propagators taking part in the 
current Z function. Their Kabbala values will be multiplied up and returned. 

7. Z_X() calculates an X function and translates a simple combination of ar- 
guments into the full hst and calls Elementary_Zf uncs : :X(). Note that this 
method takes into account a sign convention which permits the proper handling 
of the four-momentum current. 

8. Z_S() works in the same way hke Z_X(), but calls 
Elementary_Zf uncs : : S () . 

9. Z_Z() translates the simple notation of an elementary Z function into the full 
call of Elementary_Zf uncs : : Z() . 

10. Z_Y() works like Z_Z() with a shght difference. Here, it can happen that both 
couplings are zero. In this case the value 1 will be returned. 

11. Z_M() calls directly Elementary_Zf uncs : :M() without any translations. 

The Elementary_Zf uncs form the last step on the ladder to the calculation of the 
different Z functions. In this class they will be finally calculated and the 
String_Generator is filled with the different Z functions. At least two methods 
exist for each function, one for building the string part and the second to calculate 
the appropriate Z function. Sometimes different methods exist for different calling 
sequences within the string libraries. 

1. The methods Z(), Y(), X() and S() calculate an elementary Z, F, X func- 
tion or a scalar product of two four-momenta and provide its value for the 
String_Generator(). Therefore all arguments and couplings will be filled 
into one list. Now, all propagators which have numbers larger than 99 will 
be mapped onto real four-momenta (i.e. with numbers smaller than 100) via 
Map(). Then, the value of the function can be calculated via the appropriate 
{Z,Y,X,S}calc() and translated into a Kabbala type value with 
String_Generator : :Get_{Z,Y,X,S}number(). Note that in case a string is to 
be built, the function with all arguments is stored within the String_Generator. 
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2. The methods ZcalcO, YcalcO, XcalcO andScalcO calculate an elementary 
Y, X, Z function or a scalar product according to Tabs. 1, 2 and 3, respectively. 

3. P() calculates the value of a propagator and fills it into the String_Generator. 
First of all, the number of the given propagator will be determined via 
Basic_Sf uncs : : Get_Mom_Number () . Then, the value is calculated with 
Pcalc (Flavour f 1, . . . ) and translated into a Kabbala value 
(String_Generator : : Get_Pnumber ()). 

4. Pcalc (int f 1, . . . ) translates the integer valued kf-code into a proper 
Flavour () and calls Pcalc (Flavour fl, . . .). 

5. Pcalc (Flavour fl, . . .) calculates the value of a propagator using 
Propagator . 

6. Propagator () calculates the value of a propagator for a given four-momentum 
squared and the Flavour. Note that different types of the Flavour gain dif- 
ferent extra factors, i.e. fermionic and scalar propagators yield an extra factor 
of i and vector boson propagators get a —i. 

7. Mass_Teriii() generates the extra mass term which occurs during the decom- 
position of the fermionic propagator into spinor products. The first step is 
to determine the Flavour of the propagator from the given number. Then, 
the mass term is calculated with Mass_Term_Calc( ...» Flavour f 1) and it is 
filled into the String_Generator (via Get_Massnumber()). 

8. Mass_Term_Calc( . . . , int fl) translates the given kf-code into a proper 
Flavour and calls Mass_Term_Calc( . . . , Flavour fl). 

9. Mass_Terin_Calc( . . . , Flavour fl) calculates the mass term. 

10. M() determines the mass for a given particle number in case it is a propagator. 
This method is used for the calculation of the mass terms in massive vector 
boson propagators. The term is then filled into the String_Generator () 
as a complex number (Get_Enumber()). 

11. MapO translates a given propagator number (> 99) into a proper four-momentum 
number. Therefore the list of Pf uncs is searched for the given number. Now, 
the new number is determined from the appropriate Pf unc using 

Basic_Sf uncs : : Get_Mom_Number () . 

We now turn our attention to the calculation of the basic functions which are neces- 
sary for the determination of every Z function. 



77 



The structure Momf unc represents a four-momentum of a particle. Since in this 
structure not only incoming and outgoing momenta, but also the four-momenta of 
the propagators are stored, a list of arguments is available as well (compare Pfunc). 

The class Basic_Sfuiics generates and translates a list of four-momenta, i.e. 
Momfuncs, into the basic functions of the hehcity formahsm, see Eq. (2.23) for the 
S functions and Eq. (2.25) for the definition of the // and rj functions. With these 
tools, all other Z functions can be calculated: 

1. The ConstructorO initializes the list of Momfuncs with the call to 
Initialize_Momlist . 

2. Initialize constructs all necessary lists, i.e. for the /x-, rj-, Sq- and ^i- 
functions which correspond to the S{+, •) and S{—, ■) functions. Furthermore, 
a hst of masses for the different particles is created which is used later on for 
the determination of the // functions. 

3. Initialize_Momlist constructs the list of Momfuncs for the incoming and 
outgoing particles. Since at this stage no propagators will be initialized, the 
list of arguments is filled only with the number of the particle. At the end the 
current number of Momfuncs is returned. 

4. Build_Momlist adds to the list of Momfuncs all possible propagators. A loop 
over the given list of Pf uncs ensures that all propagators will be covered. First 
of all, a check will be enforced, if the current propagator is already in the hst 
with Get_Mom_Number(). This method returns the number of a given Pfunc 
in the list of Momfuncs or returns a —1 in case this propagator does not exist 
within the list. Now, a new Momfunc can be established, where the list of 
arguments will be taken over from the Pfunc. At the end, the new number of 
Momfuncs will be returned. 

5. Print_Momlist prints the current list of Momf uncs including the dependencies 
for every propagator type momentum. 

6. Get_Mom_Number returns for a given Pfunc the number of its propagator in 
the list of Momfuncs. In case this propagator does not exist, a —1 is returned. 
Accordingly, a loop over all existing Momfuncs is performed. Each list of ar- 
guments for the current Momfunc and the Pfunc are now compared. In case 
they are equal, the current number of the Momfunc is returned. Note that the 
comparison is sensitive to different sequences within the list of arguments. 

7. Calc_Momlist initializes the list of Momfuncs. This means that the Momfuncs 
for incoming and outgoing particles will be simply set and all propagators are 
calculated depending on the given four-momenta using the list of arguments 
and the sign of each particle (see SignO). 
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8. sets is the main method which is called from outside for every new combina- 
tion of incoming and outgoing four-momenta. Here, all the different functions 
as well as all four-momenta for the propagators will be calculated in the fol- 
lowing steps: 

• First of all, the four-momenta of all propagators will be calculated with 
Calc_Monilist(). 

• Now, within a loop over all Momfuncs all /x- and ^^-functions will be set. 
However, whereas the r^-functions can be calculated without any ambigu- 
ities, the sign of the yU-functions depends on the particle or anti-particle 
character. In our notation a minus sign comes with: 

— All anti-particles which do not correspond to the first incoming par- 
ticle and 

— the first incoming particle which is not an anti-particle. 

All other particles yield no sign. Note that the sign should have no infiu- 
ence for the propagator part of the Momfuncs. 

• In the last step the 5*0- and 5'i-functions will be calculated using an outer 
and an inner loop over the Momfuncs, since these functions depend on two 
four-momenta. The different relations between the functions will be used 
in order to minimize their number to be evaluated. 

9. N() returns the normalization factor for two given four-momenta. This method 
is used during the calculation of the normalization for the massless vector boson 
polarizations. 

10. Momentum returns the four- momentum for a given particle number by search- 
ing the list of Momfuncs. 

11. The methods S0(), Sl(), mu() and eta() return S{+;pi,p2), S{—;pi,p2), Ijl{p) 
and r]{p). 

12. SignO returns the sign of a momentum, i.e. a —1 for incoming and a +1 for 
outgoing particles. 

13. FlavO returns the Flavour of the given particle. 

4.3.5 Calculating the Color matrix and the Coulomb factor 

The class Color calculates all color factors from the list of Cf uncs and the appropriate 
strings of color matrices which have been established in the class Color _Generator() . 
Therefore, the fist of Cf uncs will be first shortened and then the calculation is per- 
formed by manipulating the color matrices in form of a character string, the different 
replacement rules are listed in Tab. 18. 
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Method 


Replacement 


Single_ReplaceFT() 


jabcrpc 


if^rparpb _ 


_ rpbrpa^ 




Single_ReplaceF 




rpb rpc \ 

^jk-'-ki) 


Replace! () 


rparpa ^ 
-'-ij-'-kl — 2 


^il^jk — 


-^^ij^kl 






Special case: T^^JJ; 




ReplaceDO 


Sii = 3 









Table 18: The replacement rules for the different methods in the class Color. 

1. The Constructor calculates all elements of the color matrix or reads them 
in from a saved file in the following steps: 

• At first, all diagrams (the list of Single_Amplitudes) will be switched on. 
Later on, this switch will be used to discard a repeated calculation of the 
color factor for identical color structures. 

• The data file Color.dat will be probed. In case the color factors have 
been already determined and saved into this file, they will be read in and 
the Constructor () can be terminated. 

• If the color factors have not been calculated before, their determination 
starts with finding out all equal color structures. This is mandatory in 
order to reduce the number of the color factors to a minimum. It is 
performed in two steps: 

(a) All color matrices (i.e. Cf uncs) will be brought into the same form, i.e. 
the propagators will be unified. Therefore the numbers of all incoming 
and outgoing particles will be searched in the list of Cf uncs for one 
diagram. If the appropriate number has been found (every number 
has to emerge once), a propagator which stands in the same Cf unc will 
be changed to a number beginning from 120 (these numbers do not 
occur in the usual numbering scheme for propagators, see Tab. 12). 
All other occurrences of this propagator in the current list of Cf uncs 
will be altered accordingly. This procedure ensures that identical 
Cf uncs in different diagrams have the same numbering order for the 
propagators. 
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(b) Now, the list of Cf uncs for all diagrams can be compared. If two list 
of Cf uncs exactly coincide, one of them will be dropped by switching 
of this diagram. In a hst of identities the occurrence of the duphcate 
color structure will be saved in order to build the full matrix of color 
factors at the very end. 

• Now, all products of the remaining color structures can be evaluated. 
Loops over the graphs ensure that every diagram will be connected with 
all other diagrams in order to fill the full matrix of color factors. This is 
done by multiplying the string form of the color structure for the current 
diagram with the string of the conjugated color structure of the second 
diagram. Accordingly, the value of this string has to be determined fol- 
lowing these steps: 

(a) Both strings will be translated into a binary string tree with the 
method String_Tree: :String2Tree(). 

(b) All structure constants Fabc will be replaced with a combination of 
generators T^^ with the method ReplaceFO. This is done for both 
strings separately. 

(c) Now, the strings will be multiplied by creating a new sknot of the 
binary string tree, where the operation is a multiplication and the 
string trees hang on the left and right hand side of the new root 
sknot. 

(d) All brackets will be expanded (String_Tree : :Expand()), and the 
tree is brought into a linear form (String_Tree : :Linear()). Now, it 
will be sorted with String_Tree: :Sort(). 

(e) At this stage all generators T^^ will be replaced or combined to delta 
functions Dab with Replace! (). 

(f) Now, within the string only constants and delta functions are left. 
Again, the string tree is expanded, linearized and the delta functions 
will be replaced with the method ReplaceDO. 

(g) A string tree, where only constants exist, can be easily evaluated with 
the method String_Tree: : Color _Evaluate() and the color factor is 
now available. 

• Having filled the matrix of color factors for the irreducible cases, the full 
matrix can be determined. 

• At the end the matrix of color factors will be saved into a file for later 
usage. Note, that the user might switch of individual diagrams by means 
of this matrix, i.e. by setting the corresponding colour factors to zero. 

2. ReplaceFO replaces all occurrences of the structure constants Fabc with gen- 
erators T^, see Tab. 18. A loop over the different steps of replacements ensures 
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that at the very end no structure constant is left over. At first the method tries 
to find combinations of structure constants and generators, i.e. with the same 
color octet indices and replaces them. This step is performed with the method 
Single_ReplaceFT() which is repeated until no such combination exists any 
more. Prior to each call of this routine, the string tree is expanded and lin- 
earized with the methods String_Tree : :Expand() and String_Tree : : Linear (), 
respectively. Then, if any structure constants arc still left, a single structure 
constant will be replaced with the method Single_ReplaceF() . During the re- 
placement new generators appear which can be combined with any remaining 
structure constants, i.e. the loop starts again. 

3. Single_ReplaceFT() changes a combination of a structure constant Fabc and 
a generator T,^ with one common color octet index into a combination of gen- 
erators, see Tab. 18. Therefore, an expanded and linearized list is searched for 
such combinations. This is done recursively in the following way: First of all a 
multiplication operator is looked for, where a generator or structure constant 
is attached at one side of the sknot. Then, all the other factors of this multi- 
plication series are searched for the appropriate color index. If a match occurs, 
the two factors will be replaced by the combination of generators. Special care 
has to be taken for the sign of the product, which depends on the place of 
the matched color index in the list of arguments for the structure constant. 
Since the binary tree is searched recursively for such a combination, two calls 
to Single_ReplaceFT() at the end ensure this procedure. 

4. Single_ReplaceF() replaces a structure constant Fabc by a combination of 
generators, see Tab. 18. A simple find and replace strategy in the binary 
tree is the underlying idea of this method. Note that only the first structure 
constant will be substituted, since in a global strategy it is faster to search 
for combinations of structure constants and generators (see the proceeding in 
ReplaceFO). 

5. Replace! () substitutes all the combination of two generators with a number 
of delta functions, see Tab. 18. Since the product of all generators has to 
yield a complex number, no generator will be left after this method. The 
procedure is quite simple, since we have an expanded, linearized and sorted 
binary string tree. Primarily this means that generators with the same color 
index are immediate neighbours. Therefore, only these two neighbours have 
to be combined. A further simplification can be achieved, if one of the matrix 
indices of the two generators are equal. However, in this way all generators will 
be replaced recursively by calling Replace! () twice at the end of the method. 

6. ReplaceDO applies in an expanded and linearized binary string tree all delta 
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functions. This means especially that at the end of this method no delta 
function should remain (usually this method is called, when no color matrices 
exist any more). First of all, a delta function will be searched, where two 
different cases can occur: 

(a) Both arguments of the delta function are equal. Then this delta func- 
tion will be replaced by a factor of 3 (according to the underlying group 
structure) . 

(b) The arguments could differ. Then, all other delta functions which are 
multiplied with the current one, are searched for the first argument of the 
delta function which is then replaced by the second argument. At the end, 
the current delta function was applied and will be substituted by a factor 
of 1. 

Two recursive calls to ReplaceDO ensure that the whole binary tree is exam- 
ined. 

7. Mij () returns the appropriate entry of the color matrix. 

coulomb calculates the Coulomb factor of an amplitude with two W bosons. This 
is a first higher-order correction which takes into account a Coulomb force between 
the two, slow moving, W bosons: 

1. The ConstructorO builds the matrix of Coulomb factors. Note that only 
products of a graph and a complex conjugate graph will be considered, where 
both graphs have two W bosons. After the matrix was constructed it will be 
filled with the method Build_Matrix() . 

2. Build_Matrix() searches for every graph which has two W bosons and marks 
them with the method Single_Amplitude: :Set_coulomb(). Then, at each 
place in the Coulomb matrix, where two marked diagrams meet, the value 1 
will be entered. 

3. Calculate evaluates the Coulomb factor for a given point in the phase 
space, i.e. a list of four-momenta for the incoming and outgoing particles with 
Eq. (2.40). For the calculation the momenta of the two W bosons are manda- 
tory and will be determined with the help of the given four-momenta. Now, 
all ingredients are at hand for the evaluation of the Coulomb factor. 

4. Factor returns one plus the Coulomb factor multiplied with the appropriate 
matrix element of Coulomb factors. 

In the long run, this class will be expanded to top-pairs etc.. 
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4.4 The Strings 

Within this section all basic methods to construct strings and save them into libraries 
will be explained. The basic motivation is the following: For every graph and helicity 
combination one expression consisting of algebraic operations and Z functions exists. 
Usually the value of this part of the amplitude can be calculated directly, but this 
has several large disadvantages: 

1. Every Z function is calculated in the very moment it is used. Hence some of 
the Z functions will be calculated more than once. 

2. The sequence of operations between the different Z functions has to be deter- 
mined for every sample of external four-momenta again, since it could not be 
stored. 

3. A lot of helicity combinations can yield zero which is usually reflected in a Z 
function. Nevertheless, all Z functions belonging to this combination will be 
calculated because a direct calculation is not very flexible. 

These problems can be simply cured by the following steps, respectively: 

1. Every Z function will be stored with its value and its list of arguments. Now, 
every Z function has to be calculated only once at the beginning. This task is 
performed by the String_Generator () . Accordingly, every Z function which 
was calculated in the class Elementary_Zf uncs will now be stored into a list. 

2. The whole expression for the calculation can be casted into a character string. 
Accordingly, for every sample of four-momenta only this string has to be calcu- 
lated. However, several problems occur during the generation and calculation 
of this string: 

• The string has to be built during the evaluation of the amplitude which 

results in a quite complicated program code, since every algebraic oper- 
ation has to be stored. A simple way out is the usage of a class called 
Kabbala which allows a simultaneous generation of a string during the 
calculation of complex numbers. 

• The calculation of the string is very time consuming, since this string has 
to be interpreted, i.e. the algebraic expression has to be examined and 
evaluated accordingly. The way out is the translation of this string into 
a binary string tree (String_Tree). This tree has an operation saved at 
each knot and the Z functions at the leafs, i.e. end points of the tree. 
Now, during the calculation this tree has to be followed only and every 
operation has to be performed using the values of the left and the right 
hand branch of the appropriate knot. This usually saves a lot of time 
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during the evaluation. However, the by far fastest interpreter of an alge- 
braic expression is the C++ compiler itself. Accordingly, all strings will be 
written out into C++ files, translated and linked for the evaluation. This 
will be performed within the class String_Output and is the optimal way 
of calculating an expression within AMEGIC++ . 

3. The last problem belongs to the unnecessary calculation of zero parts of the 
amplitude. Again, the translation into a character string can help to omit these 
parts. Since all zero Z functions are well known during the first evaluation of 
the amplitude, all connected parts can be deleted within the character string. 
Of course, having the string in form of a binary tree relieves this task a lot. 

In our description of the single classes we now start with the String_Handler which 
is responsible for the whole organization. Then, we proceed with the 
String_Generator family which takes care for the proper storage of the Z functions. 
In order to manipulate a string (for instance to delete zero parts), a representation of 
a string, namely a String_Tree, was chosen. This form allows an easy modification 
and evaluation of the strings. If the strings are at hand, they have to be saved 
into a hbrary form, i.e. a C++ file which later can be translated and linked. The 
classes Value and String_Output are responsible for this task. Last but not least 
two helper classes are introduced, one for the handling of strings (MyString) and one 
for tracking algebraic expressions (Kabbala). A short description of all these classes 
can be found in Tab. 19 and their relations are exhibited in Fig. 18. 

4.4.1 The Handling of strings 

The String_Handler organizes the whole string generation, the output of the strings 
into libraries and their calculation. Therefore it not only handles the 
String_Generator for the storage of the Z function but also saves the character 
strings which have been generated during the evaluation of the amplitudes. These 
strings can now be translated into a binary tree form. In order to calculate them, a 
connection between the leafs or end points of the string and the real Z functions has 
to be drawn which is done as well in this class. At the end an output into C++ files 
is performed. 

1. The Constructor of this class initializes the String_Generator, where three 
different cases could occur: 

(a) No string should be generated at all and therefore a No_String_Generator 
which is a dummy class, will be constructed. 

(b) A string should be generated, i.e. a regular String_Generator is con- 
structed, but no library should be used. 
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Class/Struct 


Purpose 


String_Handler 


Handles all string manipulations. 


ZXlist 


This list will be built from the String_Generator 




and all values necessary for the calculation of a string 




are stored here. 


VirtuaLString_Gcnerator 


The mother class of all String_Generators. 


No_String_Generator 


Calculating an amplitude without generating 




any string requires this class. 


String_Generator 


Translates all Z functions into strings, 




stores and calculates them later on. 


String_Tree 


Translates an algebraic equation into a binary tree. 


sknot 


Is a string knot of this binary tree. 


sknotlink 


Is a hst of sknots. 


Values 


Is the mother class of all connected libraries. 


Strmg_Output 


Maintains the output into C++ files. 


MyString 


A class for handling strings, i.e. adding or searching 




for strings etc.. 


Kabbala 


Strings (shem) and complex numbers 




(rishpon) in one term. 



Table 19: A short description of the string classes. 

(c) An already produced string library shall be used for the evaluation. In 
this case no string will be generated either. However, if no string library 
exists, it will be created. 

In the latter two cases an identity, i.e. a name, has to be produced in order 
to label and identify the appropriate library. 

2. Get_Generator() returns a pointer to the current String_Generator. 

3. InitO initializes a matrix of sknots, where every knot represents the root of 
a String_Tree, i.e. a tree representation of a string. The different elements are 
labeled by the graph number and the appropriate helicity combination. In this 
way, all character strings for the different parts of the amplitude can be stored. 

4. Set_String() performs the translation of a given string into a binary string 
tree, deletes all zero parts and stores the result into the matrix of sknots. For 
this purpose a String_Tree object is constructed and filled via the translation 
method String_Tree: :String2Tree(). Now, a full binary tree of strings is 
available, where every knot belongs to an algebraic operation (+,—,*,/) and 
every end point can be identified with a Z function. However, since all Z 
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Figure 18: The String classes are responsible for writing the helicity amplitudes into C++ 
files. 



functions with the string identity Z[0] yield zero, these parts can now be deleted 
with String_Tree: : Delete (). Note that the current String_Tree () is a local 
object only and a translation into a global String_Tree object is mandatory 
which is achieved via String_Tree: :Copy(). The root of this tree can now be 
stored into the matrix of sknots, where the place is determined through the 
current graph and helicity number. 

5. Complete is performed when all character strings are already stored in the 
matrix of sknots. Here, all Z functions which are attached at the end points 
of the different binary trees will be connected with the Z functions stored in 
the String_Generator. This step is mandatory, since until now, the list of 
Z functions was generated independently of the character string representing 
the algebraic expression for the calculation of one part of the amplitude. In 
order to calculate the full algebraic equation with the help of the binary tree. 
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the values of these Z functions have to be known. On the other hand, all Z 
functions are stored in the StrirLg_Generator. Therefore links between these 
different representations have to be drawn. 

Within loops over the number of graphs and helicities the binary trees are 
handled one by one. At first, all leafs are collected with the method 
String_Tree : : Get_End() , where a list of sknots will be produced. Now, every 
leaf is connected with the appropriate Z function via 

String_Generator : :Get_Kabbala(). At the very end, all Z functions which 
do not appear in the strings any more (i.e. they belonged to zero parts of the 
term) are deleted via Z_Kill(). 

6. Z_Kill() simply deletes all Z functions which do not appear in a string any 
more. Therefore, a loop over all Z functions is performed. Every string from 
all graphs and helicity combinations is searched for the appropriate function. 
Of course, since composed Z functions consist of strings themselves, they have 
to be searched as well. At the very end, if the Z function could not be found 
in any of the strings, it will be deleted via String_Generator : :Kill_Z(). 

7. Calculate determines the value of all stored Z functions using the method 
String_Generator : : Calculate (). This is the first step of the evaluation of 
the whole amplitude. 

8. ZvalueO calculates the value of the string in the form of a binary tree for a 
given combination of graph and helicity employing the method 
String_Tree : : Evaluate () . 

9. Output () generates the libraries from the strings. Therefore, a String_Output 
object is generated and the output is performed using 

String_Output : : Output () . 

10. Set -Values () chooses the hbrary to be used from a given identity. 

11. Is_String() returns 1, if all strings are established. 
4.4.2 Generating the strings 

The structure ZXlist contains all informations about a Z function, i.e. all arguments, 
the value, the type of Z function, a pointer to a String_Tree for the composed Z 
functions and an on-switch. Note that we use the label Z-f unction for a variety 
of functions which differ by their type, i.e. a real Z function, an X function, a Y 
function, a complex number, a scalar product of two four-momenta, a S function, 
a coupling, a propagator, a composed Z function and a mass term. Any algebraic 
equation for the determination of an amplitude can contain only these possible pieces. 



88 



The basic structure for all String_Generators is Virtual_String_Generator 
which is a purely virtual class. Therefore it contains only virtual methods which are 
overwritten in the derived classes. Accordingly, these methods will be described in 
these classes. 

The No_String_Generator is a dummy class. Its methods only return the given 
complex value and are used to keep the same program structure for a pure calculation 
without the generation of any strings. 

The String_Generator is used to generate and store all different types of Z 
functions. The idea is that every Z function depending on its list of arguments is 
stored only once. For a representation within the algebraic expression in form of a 
character string these Z functions have to gain a number as well for later recognition 
during the evaluation. Therefore, the main tasks are comparing a new Z function 
with all existing ones as well as creating a new one and storing it in the list of ZXlists 
in case it does not yet exist and finally returning an appropriate string representation 
including the number of the Z function. Accordingly, most methods are concerned 
with comparing arguments of Z functions, storing and calculating them: 

1. The Constructor generates a new list of couplings, flavours and ZXlists. 

2. Reset deletes the contents of all hsts. 

3. {Z,X, Y}_Number has the aim to give a well defined number for any {Z, X, F} 
function. For this purpose, it compares the list of arguments and couphngs for 
the appropriate function with all already stored {Z, X, y} functions. In case 
a complete match can be achieved the number of the function is returned, 
otherwise a —1 will be passed back. In this way a double counting of any 
function can be omitted. 

4. ZX_Count() counts the number of all ZXlists. 

5. {Z,X,E}_Count () counts the number of {Z,X,E} functions, where the latter 
one represents a complex number. 

6. Get_Cnumber() compares a given coupling with all other couplings in the list. 
If the coupling could be found, the number within the list is returned, otherwise 
the new coupling will be attached to the list of couplings. 

7. Get_Fnumber () works in the same way as Get_Cnumber () , but for the list of 
Flavours. 

8. Number () constructs a Kabbala (i.e. a string and a complex number in one 
class) out of a given complex value and a number for the Z function. The 
string part of the Kabbala is generated in the form of "Z [Z_number] " . 
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9. Get_Znumber is the method called from the class Elementary_Zf uncs. The 
input is the list of arguments, the list of couplings and the value of the Z 
function. First of all, the list of couphngs is translated into a list of numbers 
which hint on a global list via Get_Cnumber(). Then, the number of the Z 
function in the list of ZXlists is determined with the method Z_Number(). If 
this Z function already exists, the Kabbala value is returned. Otherwise a new 
ZXlist will be created. Therefore the lists of arguments and couplings as well 
as the Kabbala value (via Number) are filled into a ZXlist. 

10. Get_Xnumber() works in the same way like Get_Znumber() for X functions. 

11. Get_Ynumber() works in the same way like Get_Znumber () for Y functions. 

12. Get_Enumber () adds a complex number to the list of ZXlist (this could be 
the mass of a vector boson for instance). Therefore the existing list is searched 
for this complex number and a new ZXlist is attached in case it could not be 
found. 

13. Get_Pnumber() adds a propagator term to the list of ZXlists. Here, the com- 
plex values and the flavour of the propagator are compared with the existing 
hst. 

14. Get_MassnTimber() adds a mass term to the hst of ZXlists. These terms occur 
during the transformation of fermion propagators into spinor products. The 
complex value of the term as well as the flavour are compared with the existing 
hst. 

15. Get_Snumber adds a scalar product of two four-momenta to the list of ZXlists. 
The two arguments, i.e. the numbers of the four-momenta, are compared with 
the existing list. 

16. Get_CZnumber() adds a composed Z function to the hst of ZXlists. These 
functions occur, when the building blocks for the calculation of a multiple 
boson vertex will be stored as an extra Z function. Therefore only the complex 
values are compared with the already existing list. However, since a composed 
Z function consists mainly of an algebraic equation in form of a string, this 
string has to be stored. In order to speed up the evaluation, the string is 
first of all translated into a binary tree. Then the zero parts are deleted (i.e. 
where a Z[0] function occurs) and the end points of the tree are connected 
with the real Z functions. Within the ZXlist only the pointer to the root 
of this tree is stored (a similar treatment can be found within the method 
String_Handler : : Complete ()). 
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17. Calculate evaluates all complex values for the different Z functions of the 
list of ZXlists. Accordingly, the different methods of the class 
Elementary_Zf uncs are employed, see Tab. 20. In case a string library is linked 
this job is performed by Values: : Calculate (). 

18. Get_Kabbala() returns a pointer to the Kabbala value of a ZXlist for a given 
string representation of a Z function. If the string consists of a complex value 
only and could not be found in the current list, a new ZXlist is created and 
attached to the list. 

19. Set_EZ() sets the pointer to the actual Elementary_Zfunc object. 

20. ZX_Max_Number returns the maximum number of ZXlists. 

21. Get_ZXl() returns a ZXlist for a given list number. 

22. Coupl_Max_Number returns the maximum number of couplings stored in the 
list of couplings. 

23. Get_Coupl() returns the coupling for a given list number. 

24. Kill_Z() switches a ZXlist off. 

4.4.3 Translating an equation into a binary string tree 

The structure sknot represents one algebraic operation and is a knot of the tree for 
a whole algebraic expression. Therefore it contains a left and a right pointer to the 
next sknots, a string and a pointer to a Kabbala value for the end points of the tree 
and an operation for the knots of the tree. 

The structure sknotlink is built from a list of sknots with a fixed number and 
contains a link to the next sknotlink. The actual number is stored as well. 

The String_Tree is responsible for the translation of an algebraic expression in 
form of a character string into a binary tree form. Every knot of the tree contains 
one operation and the leafs, i.e. end points correspond to the appropriate variables, 
i.e. for instance Z functions. Consequently, this class not only enables the generation 
of this tree but also allows its proper manipulation: 

1. Reset deletes all linked sknotlinks and therefore all sknots in the list. 

2. newskO provides a new sknot from the actual sknotlink which saves a fixed 
number of sknots, usually around 200. If all sknots are already used up, a 
new sknotlink will be created. In this way a hybrid memory management 
is achieved, i.e. something between a static and a dynamic memory allocation 
model. 
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3. String2Tree() translates a given algebraic expression represented by a string 
into a binary string tree. The string itself will be examined and recursively cut 
into pieces in the following steps: 

(a) If the string is empty a zero pointer will be returned. 

(b) According to the priorities of the different operators (+,*, etc.) the sum- 
mations and subtractions are examined first. Therefore the string will 
be searched for global plus and minus signs, where global means that at 
the very point, where the sign occurs, the number of opening and closing 
brackets must be equal. If a plus sign is found this way, a new sknot will 
be created with the plus operation. The whole string will be cut into a 
left and a right hand part with respect to the place of the plus sign. Con- 
sequently, the left and the right pointer of the sknot are set by recursively 
caUing the method String2Tree() with the left and right hand part of 
the string. Now, the new sknot will be returned. The procedure for the 
minus sign is the same, only the right hand side of the string obtains an 
overall minus sign, and both parts are added. 

(c) Since at this stage all global plus and minus signs are already treated, only 
global multiplications and divisions can occur. If a global multiplication 
was found, a new sknot is created in the same manner as for the plus 
sign. The same holds true for global divisions. 

(d) At this stage no global sign should occur any more (expect leading plus 
and minus signs). Now, an expression can be enclosed by brackets and 
therefore global brackets which open at the first character of the string 
and close at the last one are removed and the examination of the strings 
continues with point (b). 

(e) If no global brackets can be removed, a leading sign could appear, i.e. a 
plus or minus sign at the first character of the string. In case it is a plus 
sign it could be simply removed, for a minus sign a new sknot will be 
built with the left side pointing to a sknot with a '0' string and the right 
hand side to the sknot which will be created through a recursive call to 
String2Tree () with the rest of the string as an argument. 

(f) At the very end only a term with no internal structure can remain. This 
rest string is stored into a new sknot which has a zero as operation. Thus 
it is marked as a leaf of the tree and will be returned. 

In this way the whole string can be translated into a tree and the method 
returns its root. Note that the different knots of the tree are stored internally 
in this class. 
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4. Color_Evaluate () calculates the value of a string originating from the deter- 
mination of the color coefficients of the amplitude. Accordingly, only a distinct 
number of different strings could emerge at the end points (i.e. these are in- 
teger numbers, color factors like Cp and imaginary units). Therefore they are 
handled within this method. The evaluation is performed recursively, i.e. the 
operation of the sknot is examined and accomplished accordingly by recursive 
calls of Color_Evaluate() with the knot of the left and right hand side, re- 
spectively. If the knot is an end point, the string of this sknot is compared 
with the different possibilities and the value is returned. 

5. Evaluate () calculates the complex value of a string in the same way as 
Color _Evaluate() with a slightly different treatment of the end points. Since 
this method is used for the evaluation of strings consisting of Z functions, 
the end points are connected to the real values of the Z functions which are 
calculated elsewhere (i.e. in String_Generator). Therefore the value of every 
end point is obtained by using the pointer value of the sknot. 

6. Get_End() is used for linking the end points of the tree with the Z functions. 
Consequently, a list of all end points is mandatory in order to draw the con- 
nection. This list is constructed in this method recursively. 

7. Tree2String() translates a binary tree back into a string. Of course, a tree 
does not contain any bracket structure and to reestablish these is the main task 
of this routine. A "granny" knot is used in order to avoid an overburden bracket 
structure. Now, simple summations do not need an extra bracket, when the 
granny option was a plus as well. The output is therefore easy to read and often 
much better than the string which originally was filled into the tree. Note that 
in its most simplest form the String_Tree can be used to simplify the bracket 
structure of a string term. 

8. Tree2Tex() works in the same way as Tree2String() , with the difference 
that the output string is LaTeX conformable. This means in particular that 
the multiplications are replaced by a space and the division is substituted by 
LaTeX commands. 

9. Delete () deletes all parts which are connected with a given zero string for 
a binary string tree. This method is used to drop all zero parts of a helicity 
combination. Since this can not be cast into a completely recursive procedure, 
a loop over calls of Single_Delete() is performed until all zero parts have 
been eliminated. 

10. Single_Delete() deletes recursively all parts of a tree which belong to a zero 
string: 
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(a) If the given sknot is zero or an end point the method is terminated with 
a return. 

(b) If the left hand knot is an end point and its string equals the given zero 
string it will be dropped according to the operation of the actual knot: 

• In case it is a multiplication, the actual sknot is set equal to the left 
sknot, i.e. the right hand part is deleted. 

• If the operation is a plus, the actual sknot is set to the right hand 
side, i.e. the left part is dropped. 

• The most difficult case occurs, when the operation is a minus. Now, 
the granny knot plays an important role. If no granny exists, i.e. the 
actual knot is the root, the string of the left knot is set to '0'. In 
case the granny operation is a multiplication, the string of the left 
knot is set to '0' as well. If it is a plus and the actual knot is on the 
left hand side of the granny the string of the left knot is again set to 
zero, otherwise the granny operation is set to a minus sign and the 
actual sknot is set onto the right hand side. Last but not least if the 
granny operation is a minus the same steps as in the plus case will be 
performed with a slight difference in the changing of the sign of the 
granny sknot to a plus instead of a minus. 

(c) If the left hand side has not been changed, the right hand side can be 
examined. If it is an end point and its string equals the zero string the 
following manipulations are done: 

• If the operation of the actual sknot is a multiplication, the sknot is 
set equal to its right hand side, i.e. the left part is dropped. 

• In all other cases the actual sknot will be set onto the sknot on the 
right hand side, if the left string is equal '0', otherwise it is set to the 
sknot of the left hand side. 

At the very end two recursive calls to Single_Delete() are performed using 
the sknots of the left and right hand side as arguments, respectively. 

11. Expand () expands an algebraic equation represented by a string tree, i.e. all 
brackets will be resolved. Since this is not a totally recursive method (as 
Delete 0), a loop over calls to Single_Expand() is performed until every term 
is expanded. 

12. Single_Expand() performs one single expansion, where two different cases can 
be distinguished: 

• The operator of the mother is a multiplication and the left or right hand 
sknot has a plus or minus sign as operation. This is the typical bracket 
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structure in the from of a* (6±c). Since a multiplication is a commutative 
operation the left and right hand side will be changed, if the plus or minus 
sign occurs on the left hand side. Now, only the right hand side has to be 
regarded. At this stage, a special case has to be considered, where inside 
the brackets only a minus sign emerges (a * (—&))■ Then, the sknots 
will be rearranged in order to get the form —a*b. In the usual case the 
equation will be simply transformed to a * b ± a * c. 

• The second case is connected with the break-up of extra minus signs, i.e. 
a piece of equation looks like a± {—b). Of course, then the expression will 
be simplified to gain the form a^b. 

However, if one of the two cases occur, a switch will be set which ensures that no 
more manipulations in this step of Single_Expand() can be performed. This is 
necessary, because one manipulation changes the structure of the tree in such 
a drastic way that the tree has to be reexamined from the very beginning (see 
ExpandO). Two recursive calls to Single_Expand() with the left and right 
hand side sknot as arguments, respectively finalize this method. 

Linear linearizes the sequence of multiplications, i.e. at the very end all 
multiplications are lined up. If one draws brackets around every sknot with 
a times operation the following transformation will be done {a * b) * {c* d) 
a * {b * {c * d)). This means that in the first case a sknot for multiplication 
with a multiplication on both sides will be transformed to a line on the left 
hand side with three subsequent multiphcations. This transformation becomes 
mandatory, if one easily wants to change the sequence of multiplications or 
wants to examine the different factors in a prescribed way. However, the first 
criterion is that the actual sknot has a times operation. Now, two different 
cases can appear: 

• The left and the right hand side have a multiplication operation, then the 
transformation is done (by again drawing brackets around every multipli- 
cation) in the form oi {a * b) * {c * d) c * {d * {a * b)). Note that the 
difference to the example above lies in the arbitrariness of the sequence of 
the times operator. 

• Only the right hand side has a times operator. Since all multiplications 
should by construction lined up on the left hand side, the two sides will 
be exchanged. In our example this will look like (6 * c) * a — > a * (6 * c) . 

Since this routine is built fully recursive, two calls to Linear () with the typical 
left and right hand side sknot, respectively, as arguments conclude this method. 
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14. The Sort () method assumes that an already hnearized and expanded tree (see 
Linear and Expand (), respectively) exists and sorts the line of multiplica- 
tions after their strings with help of a standard bubble sort algorithm. This 
is an interesting option, if one wants to have similar factors side by side. In 
one step (the method is of course recursive) one line of multiplications will be 
ordered. An outer loop takes care that the whole line will be perused from the 
very beginning again and again as long as one exchange within the line was 
performed. If no more changes occur, the line is considered as sorted. The 
inner loop compares step by step two subsequent factors, and exchanges them 
if the first factor is smaller (in a string notation) than the second one. At 
the very end of the method the classical two recursive calls to SortO will be 
realized. 

15. CopyO simply fills a given tree represented by its root sknot into the actual 
tree recursively. 

16. Set_Root() sets the root of the actual tree. 

17. Get_Root() returns the root of the actual tree. 

As part of further work we envision further simplifications of the strings, like identi- 
fication of common factors in different amplitudes and their replacement. 

4.4.4 Casting strings into C++ files and the string libraries 

For every process which is to be linked to AMEGIC++ a separate class (and C++ files) 
is generated. The class name is deduced from the specific and unique process- 
id and the class itself is derived from a purely virtual mother class Values. This 
class has two essential methods, namely Calculate () and Evaluate (). The former 
one is responsible for the precalculation of the Z functions and the latter one is 
used to calculate the value for a specified graph and helicity combination. All C++ 
files as well as the appropriate header files are saved in a directory which is named 
after the process as well. However, all the different files for the processes will be 
packed into one library called Process. Therefore, the Makefile for the production 
of this library has to be enhanced by the different objects from every process in 
order to make the linkage as easy as possible. The last step is the inclusion of 
the calling sequence for this special process. These statements are added to the 
method String_Handler : : Set_Values () which is saved into an external file called 
Set_Values . C. Now, the user only has to recompile the new objects via typing maie 
install. 

The String_Output produces the C++ and header files for the output into hbraries 
and manipulates the Makefile for their translation and the file Set_Values.C for 
calling the libraries from within the program. 
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1. The Constructor generates the different identities for the process path and 
the different files. Especially, all plus and minus signs from the given id will be 
erased, since these are protected operations within C++. 

2. The method Output () organizes the whole output to all C++ and header files 
as well as all manipulations. It is the method which is called from outside (see 
String_Handler) : 

• First of all, a header and a C++ filename will be generated with the help 
of the path and the id strings. 

• With the method Is_File () a check is performed, if the header file already 
exists. In this case the output will be canceled, since it is assumed that 
the whole library already exists. 

• Now, the header file, strictly speaking the head of the header file, will be 
generated via Make_Header(). 

• With the method Zf ormO the fist of Z functions which have to be precal- 
culated at every step, is created, i.e. the method Values: : Calculate () 
will be built. 

• The calculation of the different helicity combinations for the different am- 
plitudes is maintained from Values : : Evaluate () . Furthermore, for every 
amplitude a new method, named M#, where # stands for the graph num- 
ber, is generated. These C++ files will be written out with the help of the 
method Cf ormO . 

• Now, all C++ files are established and the header file can be finished. Note 
that during the output of the C++ files every new method has to be added 
to the header file for the prescription of the class. 

• At the very end the manipulations to the Set_Values.C file will be per- 
formed via caUing Add_To_Set_Values(). 

3. Is_File() returns 1, if the given filename already exists. 

4. Cf ormO produces the C++ files for the evaluation of all helicity combinations 
for all Feynman graphs: 

• First of all, a new C++ file will be generated and its name is added to the 
list of objects in the Makefile with Add_To_Makef ileO . 

• The main routine which will be called from outside, is Values : : Evaluate () 
and will be produced at this stage. From here, the appropriate method 
for the given graph number will be called. Note that for every graph one 
method will be generated. 
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• Now, a loop over all graphs will be performed in order to produce a new 
method for each graph. The only argument for these methods is the 
number of the helicity combination. 

• An equation for each of these will be written out using a loop over all 
helicity combinations. First of all each equation will be translated from 
its binary tree form into a single character string. Then, this string is 
written out, where special care is taken that each line has a maximum 
number of characters by calling Line_Forin() (this is mandatory, since 
these string expressions could be quite long) ^. 

At the end a number of C++ files is generated and recorded in the list of objects 
in the Makefile. 

5. ZformO produces the method Values: : Calculate () which is responsible for 
the precalculation of the Z functions. Therefore, the main task is the trans- 
lation of the list of ZXlists from the String_Generator into C++ statements. 
First of all, the name of the C++ file is added to the Makefile via 
Add_To_Makef ile(). Then, a loop over all ZXlists is performed, where the 
calling sequence for the calculation of the actual Z function depends on its 
type, see Tab. 20. Note that in the same way as during CformO additional 
care has to be taken for the maximum number of lines. Therefore, new files 
will be opened if necessary. 

6. Make_Header produces the head of the header which means that the class 
definition and the standard methods will be enlisted. 

7. Line_Forin() writes a given string into a file. Special care is taken to a maxi- 
mum number of line characters (usually around 70). If the maximum is reached, 
a line breaking is performed after the next operation (-|-,— ,*). 

8. Add_To_Set_Values() adds to the Set_Values .C file the call to the newly gen- 
erated libraries. Therefore, an include for the appropriate header file and a 
calling sequence within the method String_Handler : :Set_Values() is sub- 
joined. 

9. Add_To_Makef ileO enters the name of a file into the list of objects for a 
given Makefile. First of all, the given file will be searched (Search ()) and 

^Since the resulting C++ file can be rather big, an additional complication arises due to a maxi- 

imiiri line number for difFcrcnt compiler and machine types, e.g. we had some problems compiling 
the extra libraries of AMEGIC++ with a Digital Unix compiler. Therefore, the lines have to be 
counted and the different methods have to be casted into different C++ files. This is quite simple, 
but sometimes, already one single method is longer than the allowed maximum line number. Then, 
this method has to be partitioned as well. 
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Type 



Purpose 



Calling Sequence 




1 
2 



X function 
Z function 
Constant 



Elementary _Zf uncs : :Xcalc() 
Elementary _Zf uncs : :Zcalc() 

The method tries to reinterpret the constant 
as a coupling or a of a vector boson. 

These are the only constants which appear 
during the calculation. 
Elementary_Zf uncs : : Scale () 
Elementary_Zf uncs : :Ycalc() 
Elementary _Zf uncs : :Pcalc() 
A composed function will be written out in its 
string form using the method Line_Form(). 
Elementary _Zf uncs : :Mass_Term_Calc() 



3 
4 
5 
6 



scalar product 
Y function 
Propagator 
Composed function 



7 



Mass term 



Table 20: Calling sequence for the different Z function types. 

in case it already exists, the method terminates. Otherwise, the name of the 
file will be added at two different places, namely for libProcess_la_SOURCES 
and libProcess_la_OBJECTS, since these object files should belong to the li- 
brary Process. If the key word is found, the file name will be included in the 
next line. Note that for this purpose a temporary file will be used which is 
copied onto the appropriate Makefile at the very end (CopyO). 

10. CopyO makes a copy of one file. 

11. Search searches for a given string in a file. 
4.4.5 Strings and Kabbala 

MyString is the implementation of a typical string class extended by some methods 
compared to the standard template hbraries (STL): 

1. The usual standard Constructor initializes a zero string. A copy constructor 
version is available as well. 

2. remove removes a number of characters out of the string for a given position 
and the length of the piece to be deleted. 

3. c_str() returns a standard C character string. 

4. length () returns the length of the string. 
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5. substrdong int) returns a substring beginning at the given position until 
the end of the string. 

6. substrdong int, long int) returns a substring beginning at the given posi- 
tion and ending at the position plus the given length of the substring. 

7. f indO returns the position of a given substring within the string. If no repre- 
sentation could be found, a —1 is returned. 

8. insert inserts a substring at the given position. 

9. Convert (double) converts a double value into a string using Convert (int). 

10. Convert (int) converts an integer value into a string. 

11. The operators =,+ =,[],+, ==, ! = ,<< do exactly what one might expect. 
Therefore a special description will be discarded at this point. 

The class Kabbala is a representation for a string and a complex number in one 
class. The name of the class originates from the kabbalistic system which attributes 
to every character in the hebrew alphabet a certain number and tries to interpret 
the resulting number of words. In our case this class has the big advantage that 
one can calculate with Kabbalas instead of complex numbers and not only gains the 
numerical result, but also the string representation of the whole calculation. This 
is extensively used during the generation of the string libraries. Technically, this 
class provides the user with all possible operations of a complex number in the same 
syntax, but is taking care for the correct representation in a string form with all 
possible preferences of the operators and the appropriate use of brackets. Therefore 
it can be easily used instead of complex numbers. Two extra methods Value () and 
String return the complex number or the string representation, respectively. 

4.5 The Phase Space 

In this section we will describe the classes and methods used to generate the various 
channels within AMEGIC++ and to produce suitable sets of phase space points for the 
integration. The various classes are summarized in Tab. 21, their connections and 
interrelations are depicted in Fig. 19. 

4.5.1 Organization : The Phase_Space_Handler 

The class Phase_Space_Handler organizes both the generation of integration chan- 
nels and the integration by steering the corresponding classes Phase_Space_Generator 
and Phase_Space_Integrator, respectively. The methods available within the 
Phase_Space_Handler are: 
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Class/Struct 


Purpose 


Phase_Space_Handler 

Phase_Space_Integrator 
Phase_Space_Generator 


Handles the generation of integrators and 
the integration over phase space. 
Integrates the phase space. 
Generates the different channels for 
multi-channel integration. 


ChanneLGenerator 

ChanncLBasics 

ChanneLElements 


Generates one channel. 

Basic functions for channels. 

Contains all structural elements of channels, 

e.g. propagators. 


Selector 

Single_Selector 
AlLSelector 
Jet Finder 


Is the mother class of all selectors 
which perform cuts in the phase space. 
One single selector. 
A list of selectors 

A selector which cuts via jet-measures. 


Channel 

Single_Channel 

Multi_Channel 

Rambo 
Sarge 


Is the mother of all channels. 

Is one single channel. 

Is a list of channels and 

manages the optimization. 

Is one single channel (flat distribution). 

Is one single channel (antenna distribution). 



Table 21: Classes used for the generation of integration channels and the phase space 
integration. 



1. The Constructor reads in the parameters relevant for the generation of phase 
space points via Read_Parameter(). Then it initializes all possible selectors 
for phase space points. The only selector implemented in the moment is a jet 
measure, i.e. the requirement that the final state particles form distinguishable 
jets. 

2. Read_Pciraineter reads in parameters relevant for the phase space integration. 

Currently they consist of the jet scheme plus its t/cut, the relative error, at 
which the evaluation of cross section terminates and the strategy used for this 
calculation, i.e. Rambo only, or Rambo + Sarge, or multi-channel method with 
generic, process dependent channels in addition to Rambo + Sarge. 

3. Create_Integrator organizes the number of channels according to the choices 
given in the parameters. In case, the user choses to use multi-channel methods 
with process dependent channels, they are constructed amplitude-wise via the 
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Channel Basics 



momenta. The idea is the following: Any channel is correlated to one 
amplitude and produces a set of momenta accordingly. Thus, any two 
amplitudes differing by just permuting two identical particles give rise to 
a new channel which basically yields the same result as the original one. 
To avoid double counting and to keep the number of channels small, one 
of the two channels should be removed. 

The difference of permutations of momenta and particles is tested via 
Compare () . 

• they do not have the maximum number of resonating propagators within 
the phase space allowed. So, for every channel, the number of potentially 
resonating propagators is counted, non-maximal number of such propa- 
gators lead to the channel being switched off. 

5. Compare checks, if two sets of outgoing momenta and particles are just per- 
mutations of each other. 

6. Integrate calls a suitable method of the Phase_Space_Integrator to per- 
form the actual integration. Depending on the number of incoming particles, 
this is either Calculate () or Calculate_Decay(). 

7. Dif f erential creates one phase space point, i.e. one set of outgoing mo- 
menta fulfilling the criteria given by the selectors and returns the corresponding 
weight. 

8. Get_Point() returns one phase space point, i.e. one set of four-momenta for 
the incoming and outgoing particles. 

4.5.2 Channels 

Since all of the integration within AMEGIC++ is performed by invoking channels, we 
start the presentation of the various classes utilized in the construction of the phase 
space integrator and in the calculation by presenting the virtual class Channel. It 
consists of quite a number of virtual methods, used either to generate a phase space 
point, i.e. a set of four-momenta for the outgoing particles, and the weight associated 
with it (Generate_Point() and Generate_Weight ()), or for the actual phase space 
integration (Add_Point (), Variance ()), or used for the running of the multi-channel 
method. 

1. Generate_Weight is a method to generate the phase space weight of a channel 
for a given set of momenta. 

2. Generate_Point is a variety of methods generating phase space points, i.e. 
sets of momenta. 
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3. AddO adds a channel to the multi-channel integrator. 

4. Drop_Channel() drops a channel of the ensemble employed during the multi- 
channel evaluation of the phase space integral. 

5. Optimize optimizes the a priori weights ctj of the multi-channel integrator. 

6. End_Optiinize() performs the last optimization step, selecting the set of a 
priori weights yielding the smallest overall variance in all optimization steps so 
far. 

7. NameO returns the name of the channel. 

8. Set_Name() sets the name of the channel. 

9. Add_Point() adds the result for a phase space point to the overall result and 
increments the total number of points by one. 

10. Variance () returns the variance accumulated in the channel. 

11. Reset () resets the result etc. accumulated so far. 

12. Reset_Opt() resets all internal results, variances etc. used for the optimization 
procedure of the multi-channel strategy. 

13. Number () returns the number of channels. 

14. Count_Resonances() counts and returns the maximal number of potentially 
resonant propagators within one channel. 

Directly derived from it is the class RAMBO, generating phase space points according 
to a flat distribution with help of the following methods in addition to the ones 
outlined above: 

1. The Constructor initializes an array of helper functions used for the determi- 
nation of the phase space weight and calculates them. Furthermore, arrays for 
outgoing momenta squared, their masses and energies are initialized. 

2. Massive_Point () rescales massless vectors in order to bring them on their mass 
shells. 

3. Massive_Weight () calculates the weight related to the rescahng above. 

Similarly, the other default channel of AMEGIC++, SARGE is derived from Channel with 
the additional methods: 
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1. Qcd_Antenna() actually generates a phase space point according to the QCD 
antenna pattern, once after some first and last - massless - trial vector has 
been generated. For this purpose Basic_Antenna() is employed. 

2. Basic_Antenna() generates one antenna, i.e. one four vector emitted by a 
dipole. 

3. Perin_P() generates a random permutation of a number of integers with help 
of the P-algorithm in [23] . 

4. PolytopeO produces a uniform random distribution inside a polytope with 
\Ck\ < 1, Kfc - 61 < 1 along the lines of [24]. 

Last but not least, the integration by the multi-channel method is realized with help 
of the - again derived - class Multi_Channel. The methods employed here have 
already been described above. However, some of the algorithms change a little bit 
when having a multi-channel instead of just a single channel. These are: 

1. In Generate_Point () one channel i is selected randomly according to the a 
priori weights ctj to generate the point with its corresponding method. 

2. The evaluation of the multi-channel weight w for a phase space point is then 
performed in Generate_Weight () . It is given in terms of the individual weights 
Wi as 1/w — ^ai/wi. 

3. In Add_Point() the accumulative result, the result squared and the weight per 
channel are increased and the number of generated points is incremented. 

4.5.3 Generating channels 

The generation of the individual channels is steered by the class 
Phase_Space_Generator and actually performed by appropriate methods of the class 
Channel_Generator. The basic idea is to provide for every occurring amplitude one 
channel which has the advantage that all different peaking structures of a matrix 
element will be covered. The generated channels are then saved into C++ files and 
managed from a newly created class. This object has a similar name like the one of 
the process and is derived from the class Single_Channel. Consequently, the three 
different methods Generate_Point () , Generate_Weight () and Count_Resonance() 
have to decide about the current channel and call an appropriate method with the 
name C#_Momenta(), C#_Weight() or C#_Resonances() (# is the number of the 
channel) accordingly. Note that these methods will be created within the class 
Channel-Generator. However, we are going to start with the presentation of the 
Phase_Space_Generator, which is responsible for generating one new channel. It 
mainly consists of methods to initialize and manipulate files: 
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1. Construct decides, if a channel belonging to the given amplitude has already 
been realized or should be created. However, the strategy is the following: 

• The full name of the channel is constructed, including its path. Similarly, 
names for the header and the C++ file are generated. 

• The methods Add_To_Header () and Add_To_Cf ile() test first of all, if an 
appropriate header or steering C++ file already exists. If this is the case, 
these files will be searched for the current channel name, if it does not 
exist, the appropriate calling sequence and representation in the header 
file will be added. 

• Now, two different cases can emerge. If the channel was already generated, 
a new Channel type object will be created and initialized with the method 
Set_Channel . Then, the channel is ready to use and will be returned. 

• In the second case, a new channel has to be generated. Accordingly, a 
new object Channel_Generator is produced and the channel is created 
via Channel_Generator : :Make_Channel(). 

• Now, the new C++ files can be attached to the list of objects in the appro- 
priate Makefile via Add_To_Makef ile(). 

• If no header file or steering C++ file exists, the methods Make_Header () 
and Make_Cf ile() generate them. 

• At the end, the calling sequence for the newly generated channel will be at- 
tached to the file Set_Channel . C with the method Add_To_Set_Channel () . 

2. Add_To_Header() adds the three methods C#_Momenta() , C#_Weight(), and 
C#_Resonances(), where # stands for the number of the current channel, to 
a header file. This manipulation is only performed (by copying the old file 
to a temporary one, adding lines there and copying back) after it has been 
checked that the header file exist at all, and that these methods have not been 
implemented yet. 

3. Add_To_Cf ileO similarly adds the caUing sequence for these methods to a C++ 
file. 

4. Make_Header() constructs a new header file for this process, where all channels 
will be stored. Accordingly, all standard methods will be attached. 

5. Make_Cfile() generates all steering routines for this process which call the 
different channels appropriately. 

6. Add_To_Makef ileO adds a newly generated C++ file to the hst of objects in the 
corresponding Makefile. 
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7. Add_To_Set_Channel () creates the calling sequence for the newly generated 
library in the file Set.Channel .C. 

8. Is_File() checks, whether a specific file already exists. 

9. SearchO checks, whether a specific string is within a file. 
10. CopyO copies one file to another. 

Having set up the file system the actual generation of one channel is performed using 
methods of the class Channel_Generator which is derived from Single_Chaiinel. All 
three methods for handling a channel, i.e. one for generating the four-momenta of the 
outgoing particles, one for calculating the appropriate weight for a given sample of 
four-momenta and one for specifying the resonant propagators will be created in this 
class. Accordingly, in every method C++ commands and calling sequences are written 
out into a C++ file resulting in the appropriate methods. Finally these methods look 
like the example in Appendix A. 

1. The Constructor initializes the individual channel by setting the number of 
external particles, incoming and outgoing. It copies the point list and then 
calls Identify_Props() in order to mark all ^-channel particles. 

2. Identify_Props(): Starting from the first point (which carries the first incom- 
ing particle) the points of the list are connected recursively to their previous 
ones via Back_Links () , until, finally the other point related to an incoming 
particle with the flag b = — 1 is found. Starting from this endpoint, the back- 
ward links are followed and intermediate lines which are considered as i-channel 
propagators, are counted and marked on the way. 

3. Back_Links() recursively establishes backward links prev between the left 
and right offsprings of a point and the point itself. If a final point, i.e. a point 
having no left and right links has b = —1, i.e. if it is related to an incoming 
particle, this point is stored as the end point of the incoming line. 

4. Make -Channel maintains the generation of all three methods. Therefore it 
creates the C++ file and fills in the method named C#_Momenta(), C# -Weight () 
and C#_Resonances(). After the first two a call to Step_0() with accordingly 
two different options generates the body of the functions. The last method is 
simply filled with a list of all resonating propagators. 

5. Step_0 calls either Step_s () , Step_lt () , or Step_2t () , depending on whether 
zero, one, or two t-channel propagators have been found. So, to some extent 
Step_0() decides about the basic topology of the channel. Note that two 
different modes are available for the creation of a method, i.e. generating four- 
momenta and calculating the appropriate weight. In case, there is no i-channel 



107 



propagator, s is already set as the square of the sum of incoming momenta. 

The scheme to distinguish between various vectors and their squares within the 
channels, is to label them as pl2 and sl2, respectively, where 1 and 2 are the 
numbers of the external particles connected to the vectors. These numbers are 
determined using Linked_Masses(). 

6. Step_s() creates the complete decay sequence of an s-channel propagator. 
Consequently, this method is built up recursively and one recursion step con- 
sists of the decay of one propagator: 

• If the point under consideration is an outgoing particle, nothing will be 
done. 

• By calling Linked_Masses() for both the left and the right leg, the 
indices for their vectors and masses are determined. The names for the 
momenta are constructed accordingly. 

• With the help of Generate_Masses () the invariant masses squared for 
both the left and the right leg arc determined. Note that for propaga- 
tors these masses have to be generated. 

• Then the current propagator decays isotropically into the corresponding 
left and right vectors, an appropriate calling sequence will be attached 
to the C++ file. 

Finally, Step_s() is called for both the left and the right leg. 

7. Step_lt() is the root for a topology with one i-channel propagator. Simi- 
larly to Step_s() the masses squared for the two outgoing legs are determined 
calling Generate_Masses . Then their momenta are fixed by invoking the 
corresponding T_Channel_X building blocks, where X is replaced by Weight or 
Momenta accordingly. Finally, the two outgoing legs can be treated as s-channcl 
propagators by calling Step_s(). Strictly speaking this method is quite similar 
to Step_s() but the isotropic decay replaced by a t-channel decay. 

8. Step_2t() is the key stone for a topology with two t-channel propagators. The 
only differences to Step_lt() arc related to the fact that there are three instead 
of two outgoing particles, and that there are different kinematical regions for the 
two t-channel propagators, depending on whether their particles are massless 
or not. This last fact is reflected in invoking one out of a variety of strategies. 
At this point it should be noted, however, that at the present stage the only 
strategy implemented is for two massive t-channel propagators fusing into a 
massive or massless state and the two other outgoing particles being massless. 
Obviously, further reflnements here are left to further work. 
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9. Linked_Masses generates a string of numbers for a given Point which con- 
sists of all particles attached to the same branch. Starting from this Point, all 
left and right links are followed recursively and end points are added to the 
corresponding string. 

10. Generate_Masses basically produces masses squared for a list of propagators 
along the following algorithm for each: 

• By using Linked_Masses() names for the squared masses of each point 
are generated. If the point corresponds to an outgoing particle, the mass 
squared is set directly, otherwise, its minimal value is given by the square 
root of the sum of squares of the outgoing particles connected to it. 



• Now a loop over all points not treated so far starts. 

— The most resonating propagator among the points left is selected. The 
contribution of each single propagator is estimated via l/{MfTfY, 
where Mf and are the mass and width of the propagating flavour. 

— The maximal s^;^ for this propagator is evaluated which is the avail- 
able s minus all other s of propagators already dealt with and minus 
all minimal Smin of the so far untreated propagators. 

— Now the actual s of this propagator is chosen according to either a 
Breit-Wigner or a simple pole distribution for a massive or massless 
particle, respectively. 

11. Generate_Weight () and Generate_Point () are dummy methods, i.e. they are 
only used, when new Channels have been created and not linked properly. 
Then these methods give an error message. 

12. Get_Pointlist () returns the list of Points. 

13. Init_T() resets all i-flags in a Point hst. 
4.5.4 Integration 

The phase space integration, i.e. the sampling over Monte Carlo generated sets of 
four-momenta for the outgoing particles is organized by the Phase_Space_Integrator 
with help of the following methods 

1. Within the Constructor (), the number of optimization steps, the number of 
phase space points per step as well as a maximum number of phase space points 
to be generated are set. 




(4.1) 
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2. Calculate actually performs the calculation of a 2 ^ n cross section de- 
pending on a jet measure. Then the channel responsible for the integration is 
reset and during a loop points, or better the values related to them are added 
via Channel : :Add_Point (). The necessary set of four-momenta as well as the 
corresponding value of the Feynman amplitude are obtained via the method 
Differential () of the Phase_Space_Handler. Note that due to the structure 
outlined above, the channel used can be a multi-channel or just one channel. 

3. Up to some different value for the incoming flux, the method Calculate_Decay () 
is fairly similar and calculates 1 — > n decay widths. 

4.5.5 Building blocks for the channels, selectors 

The basic building blocks for the construction of specific channels have been hsted 
already in Tab. 4. The corresponding methods are organized in the class 
Channel -Elements (where X stands for Momenta or Weight): 

1. Isotropic2_X() generates momenta or the weight for an isotropic two-body 
decay. 

2. Isotropic3_X() generates momenta or the weight for an isotropic three-body 
decay. 

3. Anisotropic2_X() generates momenta or the weight for an anisotropic two- 
body decay. 

4. Massless_Prop_X() generates a mass squared or the weight for a massless 
propagator, i.e. according to a simple pole distribution. 

5. Massive_Prop_X() generates a mass squared or the weight for a massive prop- 
agator, i.e. according to a Breit-Wigner distribution. 

6. T_Channel_X() generates momenta or the weight for a t-channel propagator. 

Within these building blocks, some elementary functions are widely used, they are 
organized in the class Channel_Basics: 

1. rotate ) is used to set up 3 x 3 matrices for spatial rotations or to rotate a 
vector with such a matrix already set up. 

2. boost is used to define a boost along an arbitrary axis or to transform a 
vector with such a boost. 



3. sqlam(a,b,c) returns J {{a — h — cY — Ahc)/ a. 
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4. tjO generates a number s according to a simple pole l/(a ± s)^ with the 
corresponding arguments passed in the call. 

5. hj () yields the normalization for tj (). 

6. t j 1 () specializes t j () for the case of a pole in the form of l/(a — s)^. 

7. hjl() yields the weight for tjl(). 

8. Pseudo_Angle_Cut calculates and returns an angular cut for the i-channel 
methods T_Channel_X() above. So it basically constraints the t in the propaga- 
tor and avoids potential singularities which might occur for massless particles. 

To impose additional cuts on the phase space, the virtual class Selector is used. It 
consists of one method only, Trigger () yielding a or a 1 depending, on whether 
the cut was passed or not. This is then used in the sampling to decide, of whether a 
specific point should be added to the result, or whether a result should be added, 
in case the point generated failed to pass the cuts. 

Derived from this class is a class All_Selector which might be used for a non- 
trivial combination of constraints. 

The only selector actually implemented so far is a cut on jets which is passed if 
all outgoing particles form different jets according to some jet-measure. This selector 
is organized in the class Jet_Finder and consists - in addition to the trigger - of the 
methods: 

1. Constructor initializes the jet finder, i.e. the clustering scheme, the number 
of vectors etc.. 

2. y_jettest() determines the minimal jet-measure ymm for a number of four- 
momenta with yminO. 

3. yminO gives the minimal jet-measure for the two four-momenta out of a set, 
having the smallest yij (determined by calling jetO) according to the scheme 
selected. 

4. durhamO returns the argument in the Durham-algorithm to be compared with 

5. jadeO returns the argument in the Jade-algorithm to be compared with 

.m. ■ 

6. geneva returns the argument in the Geneva-algorithm to be compared with 

Z/cut-E'c.m.- 

7. j et is the wrapper of the three methods above. Depending on the jet-scheme 
selected, for two vectors the argument of the methods above is returned. 
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8. recombO recombines two specific vectors out of a set according to tlie E- 
sclieme. 

4.6 Pcirameters and Switches 



Table 22: A short description of the classes connected with the handhng of parameters 
and switches. 

Within the different files for the steering of the program via parameters and switches, 
a number of different data types can occur. Not only the usual C++ types int, double 
and string can be used during the input, but special types were created. Among 
them, the classes Switch and Model_Type are the most important. The first one has 
the two settings On and Off and is the standard type for all simple switches. With 
the second one, the model can be specified, where pure QCD, QCD, EW and SM are the 
possible options for a pure QCD model, a QCD model with the particles e+, e~ and 
all their interactions with the QCD particles added, a pure electroweak sector and 
the whole Standard Model. All these different types have to be handled in one list 
of parameters and switches. Therefore, an abstract and purely virtual class has to 
be constructed, from which all other Data types can be derived, i.e. a Data_Pointer. 
Now, an abstract template class. Data, is used for all different data types which play 
the role of a template parameter: 

1. Set_Name() is used to set the name of the variable. 

2. Get -Name returns the name of the variable. 

3. Get_Value() returns the value of the variable. 

4. Set_Value_Direct() sets the value of the variable directly. 

5. Set_Value() converts a given string into the current variable type. This tem- 
plate method is specified for the types Switch, Model_Type and string. 



Class/ Struct 



Purpose 



Switch 

ModeLType 

Output 

Data_Pointer 

Data 

Run_Parameter 



Can be ON or OFF. 

Gives the type of the model. 

Gives the output level. 

Is a purely virtual class for all Data. 

Is a template for reading in data. 

Steers the reading in of parameters and switches. 
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The class Run_Parameter () includes the main routines for reading in parameter files. 
Supplementary to this, the class reads in the parameter file Run.dat and provides 
the program with all parameters and switches necessary for one run. Note that the 
level of output will be steered as well, one can choose between silent, normal and 
noisy output. 

1. InitO defines all parameters and switches (i.e. type and name) which can be 
read in from the file Run.dat. Accordingly, a list of Data_Pointers is built. 
Then, all the data will be filled with the method ReadO. 

2. ReadO reads in a list of parameters and switches from a given data file. This 
list includes all possible data, where every variable has its own string name. 
Now, the data file will be searched line by line for every given string name. If 
a name could be found, the pertaining value is filled into the list accordingly. 

3. Shorten () deletes all initial and final spaces in a string. 

The rest of the methods are used to set or return the different parameters and 
switches already read in from the file Run.dat: 

1. CMS_E() returns the center of mass system energy. 

2. Set_CMS_E() is used, to set the CM-energy. 

3. Model_File() returns the name of the model file (in most cases Const.dat). 

4. Model returns the Model_Type. 

5. Model_Mass() returns a Switch: :0n, if the masses should be generated by the 
model. 

6. Masses () returns a Switch: :0n, if all masses should be taken into account. 

7. Run_Mass returns a Switch : : On, if the masses should be regarded as running. 

8. Run_Width() returns the number of the running width scheme to be used, 
means no running. 

9. Run_Aqed() returns a Switch: :0n, if oqed should be regarded as running. 

10. Coulomb returns a Switch: :0n, if Coulomb effects should be taken into ac- 
count. 

11. Mass (Flavour, double) returns the mass for a given Flavour of a particle at 
a given scale. Accordingly, a possible running of the masses will be taken into 
account in this method as well. 
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12. Mass (Flavour) uses Mass (Flavour .double) to yield the mass of a particle at 
the CM-energy. 

13. Width (Flavour , double) works like Mass (Flavour, double), but for the width. 

14. Width (Flavour) works like Mass (Flavour), but for the width. 

15. PicobarnO returns the conversion factor between 1/GeV^ and pb. 

16. Get_Path() returns the current path for all input data files. 

17. Set_Path() sets the current path for all input data files. 

18. Output returns the output level. 

19. Set_Output() sets the output level. 
4.7 Helpers 

A number of helper classes are always necessary for certain purposes. Primarily, a 
random number generator is mandatory in every Monte Carlo simulation. A tool to 
measure the elapsed time for the different methods can be used for an optimization 
and of course a three- and a four- vector should be available as well. Last but not 
least a matrix class can be used. A short description of the different classes can be 
found in Tab. 23. 



Class/ Struct 


Purpose 


Random 


Some random number generators. 


MyTiming 


A timer for measuring run times. 


vec3d 


A three-vector. 


vec4d 


A four-vector in Minkowski space. 


Matrix 


A matrix with arbitrary rank. 



Table 23: An overview of the helper classes. 



The class Random provides a number of different random number generators. An 
additional option is the possibility, to store the actual state of the appropriate gen- 
erator. This ensures that after every event a status can be saved and restored later 
on (for the examination of a special event for instance). Note that all algorithms for 
the different random number generators are taken from the Numerical Recipes [25]. 

1. The Constructor initializes the random number generator with a given seed 
via Set_Seed(). 
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2. ranlO returns a random number after an algorithm of Park and Miller with 
Bays-Durham shuffle and added safeguards, see [25]. 

3. raii2() returns a random number according to a long period random number 
generator of L'Ecuyer with Bays-Durham shuffle and added safeguards, see [25]. 

4. RanSO is a standard random number generator, see [25]. 

5. Init_Ran3() initializes the random number generator. 

6. getO returns a random number calling Ran3(). 

7. getNZO returns a random number (with getO) excluding zero. 

8. Get_Seed() returns the actual seed. 

9. Set_Seed() sets a given seed with the method Init_Ran3(). 

10. thetaO returns an angle theta which is uniformly distributed in the cosine of 
this angle. 

11. WriteOutStatusO writes out every status register of the random number gen- 
erator. 

12. ReadlnStatus () reads in every status register of the random number generator. 

The class MyTiming can be used for internal time measurements. The methods of 
this class are self-explanatory, i.e. Start (), StopO and PrintTimeC). 

The class vec3d represents an Euclidean three-vector. Typical operators, like 
-|-, — ,* and the cross product between three- vectors and *,/ of three- vectors with 
scalars are defined accordingly. An operator < < ensures a proper output of a three- 
vector, other methods are: 

1. The Constructor () is available in the form of a standard and a copy con- 
structor as well as one constructor which can be assigned with a four-vector 
(vec4d). 

2. absO returns the absolute value (length) of the vector. 

3. sqrO returns the absolute value squared. 

4. operator []() returns the element of the vector for a given place number 
(1...3). 

The class vec4d is the implementation of a four-vector in Minkowski space. All 
the usual operators, i.e. -|-, — , * between four-vectors and *, / of four-vectors with 
scalars are implemented. Additional operators are << for the output, and ! = 
for comparing two four- vectors. 
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1. Three different Constructor () are available for the four-vector, i.e. a standard, 
a copy and a constructor which can be assigned with the energy and a three- 
vector. 

2. operator [] () returns the entry of the four- vector for a given index (0 ... 3). 

3. abs2() returns the absolute value squared of the four- vector. 

4. operator+=() adds another vec4d. 

5. operator-=() subtracts another vec4d. 

6. operator*=() multiplies the current vec4d with a scalar. 

The template class Matrix represents a square matrix with arbitrary rank, where 
the rank plays the role of the template parameter. The usual multiplications with 
a matrix, a scalar or a four-vector (if the rank is equal four) are mandatory. Note 
that not all possible operations of a matrix have been implemented, since not all 
operations are necessary for our purposes. 

1. Two different types of Constructor () exist in this class, i.e. a standard and a 
copy constructor. 

2. operator=() is the copy operation. 

3. operator [] () returns a row of the matrix for a given index. 

4. matrix_out() makes a structured output of the matrix. 

5. rankO returns the rank of the matrix. 

6. Num_Recipes_Notation() translates the internal structure of the matrix into 
a numerical recipes structure. The main difference lies in the starting number 
for counting arrays, i.e. zero for AMEGIC++ and one for the numerical recipes. 

7. Amegic_Notation() translates the numerical recipes structure back into the 
internal structure. 

8. DiagonalizeO diagonalizes a matrix, i.e. calculates the eigenvalue and the 
eigenvectors with jacobiO. For this purpose a translation into the notation 
of the numerical recipes beforehand and a retranslation back into the original 
notation afterwards are performed. 

9. Diagonal ize_Sort() uses DiagonalizeO in order to determine the eigenval- 
ues and eigenvectors of a matrix. Afterwards they will be sorted according to 
their eigenvalues. 
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10. jacobiO diagonalizes a matrix, i.e. calculates the eigenvalues and eigenvectors. 
This method has been borrowed from the numerical recipes [25]. 

11. Dagger returns the transposed matrix. 
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5. Installation guide 



5.1 Installation 

The installation of AMEGIC++ is quite simple, since a combination of automake and 
autoconf was used to generate the Makefile's of the program. The first script 
translates a number of Makefile . am's, where a rough description of the object files 
is included, into a Makefile. in. The second step is the generation of a script 
called configure from a basic file configure, in which is achieved using autoconf. 
This script is able to translate an abstract Makefile, in into a proper Makefile by 
including the actual path configuration of the system. Note that these steps have 
been already performed by the authors of this program. Accordingly, the last step 
which has to be done by the user itself, is the translation of the Makefile . in's with 
the script configure. 

The steps to install AMEGIC++ are the following: 

1. The program can be downloaded in form of the file AMEGIC++-1.0.tar.gz. It 
has to be unpacked with gzip and tar. 

2. By caUing the script configure all Makefile's will be generated. Note that 
they are now adjusted to the appropriate directory structure. 

3. With the command make install all necessary libraries will be built and the 
executable will be placed into the directory Amegic, where it is ready to use. 

4. During the run of the program new C++ files might be generated by AMEGIC++. 
This is the case for the creation of new integration channels or for saving the 
different helicity combinations in form of a string. However, if this happens, a 
new translation with make install is all the user has to do. Accordingly, all 
these files will be packed into a library called Process and linked as well. 

5.2 Running 

The program is executed by the script Amegic with the directory of the parameter 
files as an argument. However, the standard directory is Testrun, where the files 
Run.dat, Const.dat, Integration.dat, Particle.dat as well as Processes.dat 
should be available. The different possible options are explained in the appropriate 
Tabs. 24, 25 and 26, whereas the properties of the Standard model particles can 
be set according to Tab. 27. Note that the particles which are marked as unstable 
will be provided with calculated decay width in AMEGIC++, the specified width in 
Particle.dat will be ignored. 

The last step is to generate a list of processes within the data-file Processes . dat. 
Every process is built in the following way: First the fist of incoming particles is 
specified using their kf-codes and an extra minus for anti-particles. The string "->" 
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now parts the list of incoming and outgoing particles, where the latter is created 
in the same way like the incoming list. A simple example for the process e~ e"*" — > 
uu could be "11 -11 -> 2 -2". Note that it is also possible to indicate a hst of 
processes which will be handled one by one. Since now all parameters and switches 
are determined, the program file could be executed. 

However, a typical sample main file in C++ which is included in the distribution 
as Amegic/main. C, should look like: 

#include "Amegic.H" 
#include "MyTiming.H" 
#include "Run_Paraineter .H" 

using namespace AMEGIC; 

Run_Parameter rpa; 

int main(int cirgc,char* argv[]) 
{ 

MyTiming testtimer; 

testtimer . Start () ; 

string nameC'Testrun") ; 

if (argc==2) name = string (argv [1] ) ; 

rpa. Init (name) ; 

particle_init (name) ; 

testtimer .PrintTimeO ; 
Amegic Test (name); 

Test .Run ; 

testtimer. Stop ; 
testtimer .PrintTimeO ; 

} 

Note that an extra time measurement is performed as well. 
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Variable 


Default 


Purpose 


CMSENERGY 


9L 


CM-energy in GeV. 


MODELFILE 


Const.dat 


Model data-file. 


MODEL 


QCD 


Model used : pure QCD, QCD, EW 






and SM. 


MODELMASS 


Off 


Take the masses of the SM-particles from 






the model data-file. 


MASSES 


On 


Quark masses. 


RUNMASS 


Off 


Running quark masses (LO). 


RUNWIDTH 





Running width scheme. 


RUNAQED 


Off 


Running electroweak coupling oqed- 


COULOMB 


Off 


Coulomb corrections. 


OUTPUT 


NORMAL 


Output level: SILENT, NORMAL or NOISY. 



Table 24: The parameters in Run.dat. 



Vaiial)k> 


Default 


Purpose 


m_up 


.005 


Mass of up-quark. 


m_down 


.01 


Mass of down-quark. 


m_e- 


.000511 


Mass of electron. 


m_charm 


1.3 


Mass of charm-quark. 


m_strange 


.170 


Mass of strange-quark. 


m_mu 


.105658 


Mass of muon. 


m_top 


174. 


Mass of top-quark. 


m_bottom 


4.4 


Mass of bottom-quark. 


m_tau 


1.77705 


Mass of tauon. 


alphas (M_Z) 


.118 


as{Mz) 


V 


246.0 


VEV of the SM Higgs-field. 


m_H_SM 


100.0 


SM Higgs mass. 


alpha_QED(MZ) 


128. 


l/aQEB{Mz) 


SinTW2 


.23124 


sin^(0Wemberg) 


lambda 


.0 


A of Wolfenstein's CKM. 


A 


.0 


A of Wolfenstein's CKM. 


rho 


.0 


p of Wolfenstein's CKM. 


eta 


.0 


77 of Wolfenstein's CKM. 



Table 25: The Standard Model parameters in Const.dat. 
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Variable 


Default 


Purpose 


YCUT 


0.01 


ycut for jet-finders. 


ERROR 


0.01 


Allowed error when calculating matrix-elements. 


INTEGRATOR 





Phase space : Rambo=0, Rambo+Sarge=l, 






Multichannel+Rambo=2, pure Multichanncl=3. 


JETFINDER 


1 


Jet-finder: DURHAM=1,JADE=2,GENEVA=3. 



Table 26: The parameters in Integration.dat. 



kf-code 


Mass 


Width 


3*e 


Y 


SU(3) 


2*Spin 


On 


Stab. 


Name 


1 


.01 


.0 


-1 


-1 


1 


1 


1 


1 


d_quark 


2 


.005 


.0 


2 


1 


1 


1 


1 


1 


u_quark 


3 


.170 


.0 


-1 


-1 


1 


1 


1 


1 


s_quark 


4 


1.3 


.0 


2 


1 


1 


1 


1 


1 


c_quark 


5 


4.4 


.0 


-1 


-1 


1 


1 


1 


1 


b_quark 


6 


174.0 


.0 


2 


1 


1 


1 


1 


1 


t_quark 


11 


.000511 


.0 


-3 


-1 





1 


1 


1 


e- 


12 


.0 


.0 





1 





1 


1 


1 


nu_e 


13 


.10565 


.0 


-3 


-1 





1 


1 


1 


mu- 


14 


.0 


.0 





1 





1 


1 


1 


nu_mu 


15 


1.777 


.0 


-3 


-1 





1 


1 


1 


tau- 


16 


.0 


.0 





1 





1 


1 


1 


nu_tau 


21 


.0 


.0 








1 


2 


1 


1 


gluon 


22 


.0 


.0 











2 


1 


1 


photon 


23 


80.356 


2.07 


-3 








2 


1 


1 


W- 


24 


91.188 


2.49 











2 


1 


1 


Z 


25 


150.0 


.0 














1 


1 


h 



Table 27: All particles included in Particle.dat. 
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6. Summary 

In this paper we presented the newly developed matrix element generator AMEGIC++ 
which is capable of calculating Feynman amplitudes as well as cross sections at tree 
level for the processes: 

1. Electron positron annihilations into jets (up to a number of six jets) and 

2. the scattering of QCD particles up to three jets. 

Two different kinds of problems occur during the calculation of the Feynman ampli- 
tude and their integration to yield a cross section. First of all, since the number of 
outgoing particles is quite large, the resulting number of Feynman diagrams is enor- 
mous (for example e~ QQgggg yields 384 diagrams in our notation). Therefore, 
the usual method of summing and squaring the amplitudes "by hand" is not suffi- 
cient enough. A way out provides the helicity amplitude method which allows the 
decomposition of spinor products into their helicity states. Now, only all other parts 
of the Feynman diagram have to be translated into spinor products accordingly, i.e. 
for instance propagators and polarization vectors. Having at hand all helicity ampli- 
tudes for a given process, the evaluation of the cross section could start. Here, the 
next problem comes into play. Since the highly dimensional phase space can contain 
a lot of differently strong peaks (i.e. resonant propagators or soft and coUinear gluons 
with respect to the quarks), the usual method of a Monte Carlo integration with a 
uniformly distributed phase space has to be abandoned. Accordingly, re-adjusted 
phase space integrators have to be produced which take care for the whole peak 
structure of a specified process. One possibility is the multi-channel integration, 
where every channel can be assigned to a Feynman diagram of the process under 
consideration. Now, every channel is built to cover the peak structure of a specific 
Feynman diagram and therefore the whole peak structure is taken into account. 

The underlying ideas of the helicity formalism and the multi-channel integration 
have been presented throughout this paper in different forms, i.e. from a theoretical, 
algorithmical and technical point of view. Primarily the detailed description of all 
classes and methods within AMEGIC++ should enable a possible user to enhance or 
simply to use the program. 

Of course, AMEGIC++ is far from being perfect, therfore a number of extensions 
are planned for the near future: 

• The list of Feynman rules and therefore Models will be extended to the Two 
Higgs Doublet and to the Minimal Supersymmetric Standard Model. 

• The program will be enabled to calculate polarized cross sections in order to 
make predictions for a possible next linear collider with polarized electrons and 
positrons. 
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• Initial state radiation will be possible for electron positron and QCD parton 
scatterings. The former one will include the Yennie-Frautschi-Suura approach 
and the latter one a structure function scheme which makes it necessary to hnk 
parton distribution functions (pdf). 

• Further technical refinements are in order, for instance parallelization, further 
simplifications of the strings, more building blocks for the integration channels, 
more phase space selectors. 

Acknowledgments 

F.K. and R.K. would like to thank Mike Bissct, Andreas Schalicke, Steffen Schumann 
and Jan Winter for extensively testing parts of the program and useful comments on 
both the program and the manual. We appreciate gratefully the careful reading of 
the manuscript by James Hetherington, Chris Harris and Peter Richardson and their 
suggestions for its improvement. F.K. would like to thank the Physics Department 
of the Technion, Israel, where parts of the work were done, for friendly hospitality. 
R.K. is grateful for the kind hospitality of the Cavendish Laboratory, where large 
parts of this work have been finalized. We acknowledge financial support by DAAD, 
BMBF and GSI. 

References 

[1] Recent results for the W boson mass and width: 

R. Barate et al. [ALEPH Collaboration], Phys. Lett. B 484 (2000) 205 [hep- 

ex/0005043]; 

P. Abreu et al. [DELPHI Collaboration], Phys. Lett. B 511 (2001) 159 [hep- 
ex/0104047]; 

M. Acciarri et al. [L3 Collaboration], Phys. Lett. B 496 (2000) 19 [hep-ex/0008026]; 
G. Abbiendi et al. [OPAL Collaboration], Phys. Lett. B 493 (2000) 249 [hep- 
ex/0009019]. 

For the Z boson mass and width sec: 

R. Barate et al. [ALEPH Collaboration], Eur. Phys. J. C 14 (2000) 1; 

G. Abbiendi et al. [OPAL Collaboration], Eur. Phys. J. C 19 (2001) 587; 

LEP Collaborations, "Combination procedure for the precise determination of Z boson 

parameters from results of the LEP experiments," hep-ex/0101027. 

Results for the top-quark can be found in: 

T. Affolder et al. [CDF Collaboration], Phys. Rev. D 63 (2001) 032003 [hep- 

ex/0006028]; 

B. Abbott et al. [DO Collaboration], Phys. Rev. D 58 (1998) 052001 [hep-ex/9801025]. 

[2] One of the many textbooks on the Standard Model is: 

J. F. Donoghue, E. Golowich and B. R. Holstein, "Dynamics of the standard model," 



123 



Cambridge, UK: Univ. Pr. (1992) (Cambridge monographs on particle physics, nuclear 
physics and cosmology, 2). 

[3] For LHC see: 

LHC Study Group Collaboration, "The Large Hadron Collider: Conceptual design," 
CERN-AC-95-05-LHC. 

For TESLA see: 

F. Richard, J. R. Schneider, D. Trines and A. Wagner, "TESLA Technical Design 
Report Part L Executive Summary," hep-ph/0106314; 

J. A. Aguilar-Saavedra et al. [ECFA/DESY LC Physics Working Group Collabora- 
tion], "TESLA Technical Design Report Part IIL Physics at an e+e- Linear Collider," 
hep-ph/0106315. 

[4] A. Pukhov et al., "CompHEP: A package for evaluation of Feynman diagrams and 
integration over multi-particle phase space. User's manual for version 33," hep- 
ph/9908288. 

[5] T. Hahn, "Generating Feynman diagrams and amplitudes with FeynArts 3," hep- 

ph/0012260; 

J. Kublbeck, H. Eck and R. Mertig, "Computeralgebraic generation and calculation 
of Feynman graphs using FeynArts and FeynCalc," Prepared for 2nd International 
Workshop on Software Engineering, Artificial Intelligence and Expert Systems for 
High- energy and Nuclear Physics, La Londe Les Maures, France, 13-18 Jan 1992. 

[6] F. Yuasa et al, Prog. Theor. Phys. Suppl. 138 (2000) 18 [hep-ph/0007053]. 

[7] T. Stelzer and W. F. Long, Comput. Phys. Commun. 81 (1994) 357 [hep-ph/9401258]. 

[8] T. Ohl, "O'Mega and WHIZARD: Monte Carlo event generator generation for future 
coUiders," hep-ph/0011287. 

[9] R. Kuhn, F. Krauss, B. Ivanyi and G. Soff, Comput. Phys. Commun. 134 (2001) 223 
[hep-ph/0004270]. 

[10] R. Kleiss and W. J. Stirling, Nucl. Phys. B 262 (1985) 235. 

[11] A. Ballestrero, E. Maina and S. Moretti, Nucl. Phys. B 415 (1994) 265 [hep- 

ph/9212246]; 

A. Ballestrero and E. Maina, Phys. Lett. B 350 (1995) 225 [hep-ph/9403244]. 

[12] R. Kleiss and R. Pittau, Comput. Phys. Commun. 83 (1994) 141 [hep-ph/9405257]. 

[13] F. Caravaglios and M. Moretti, Phys. Lett. B 358 (1995) 332 [hep-ph/9507237]. 
An implementation can be found in : 

M. Moretti, T. Ohl and J. Renter, "O'Mega: An optimizing matrix element genera- 
tor," hep-ph/0102195. 



124 



[14] F. A. Bcrcnds, R. Pittau and R. Kleiss, Nucl. Phys. B 424 (1994) 308 [hep- 
ph/9404313]. 

[15] T. Ohl, Comput. Phys. Commun. 120 (1999) 13 [hep-ph/9806432]. 

[16] C. G. Papadopoulos, Comput. Phys. Commun. 137 (2001) 247 [hep-ph/0007335]. 

[17] R. Kleiss, W. J. Stirling and S. D. Ellis, Comput. Phys. Commun. 40 (1986) 359; 
R. Kleiss and W. J. Stirling, Nucl. Phys. B 385 (1992) 413. 

[18] P. D. Draggiotis, A. van Hameren and R. Kleiss, Phys. Lett. B 483 (2000) 124 [hep- 
ph/0004047]. 

[19] D. Bardin, W. Beenakker and A. Denner, Phys. Lett. B 317 (1993) 213. 

[20] The two choices provided can be found for instance in: 

D. Bardin, A. Leike, T. Riemann, M. Sachwitz, Phys. Lett. B 206 (1988) 539; 

D. Bardin, T. Riemann, Nucl. Phys. B 462 (1996) 3; 

E. N. Argyres, W. Beenakker, G. J. van Oldenborgh, A. Denner, S. Dittmaier, J. 
Hoogland, R. Kleiss, C. G. Papadopoulos, G. Passarino, Phys. Lett. B 358 (1995) 
339. 

[21] L. Garrcn, I. G. Knowles, T. Sjostrand and T. Trippe, Eur. Phys. J. C 15 (2000) 205. 

[22] T. Ohl, Comput. Phys. Commun. 90 (1995) 340 [hep-ph/9505351]. 

[23] D. E. Knuth; The Art of Computer Programming Vol. 2, 2. Edition, Addison- Wesley, 
1998. 

[24] A. van Hameren and R. Kleiss, Comput. Phys. Commun. 133 (2000) 1 
[physics/0003078]. 

[25] W. H. Press, S. A. Teukolsky, W. T. Vetterling, B. P. Flannery; Numerical Recipes in 
C, Cambridge University Press, 2. Edition (1994). 



125 



A. Sample channel for the phase space integration 

This is the C++ file which was produced in order to generate the channel given in 
Fig. 12. Three different methods will be created, the first one for the generation of 
the four-momenta, the second one for the calculation of the appropriate weight and 
the last one for finding resonant propagators within the channel. The last option is 
used to drop irrelevant channels. 

#include "P2_5_e_e s_cb_tau_nu_tau_P . H" 

using namespace AMEGIC; 

void P2_5_e_e s_cb_tau_nu_tau_P : : Cl_Momenta(vec4d* pin,vec4d* pout, 

double* ms_out, double* ran) 

{ 

vec4d p32456 = pin[0] + pin[l] ; 
double S32456 = p32456 . abs2 () ; 

double s32_min = Max(pa.ycut_ini () *sqr (rpa. CMS_E() ) , 

sqr (sqrt (ms_out [3] ) + sqrt (ms_out [2] ) ) ) ; 
double s456_inin = McLx(pa.ycut_ini()*sqr(rpa.CMS_E()) , 

sqr (sqrt (ms_out [4] ) + sqrt (ms_out [5] ) 

+ sqrt (ms_out [6] ) ) ) ; 
double s32_max = sqr (sqrt (s32456) -sqrt (s456_min) ) ; 
vec4d p32; 
double s32; 

s32 = CE.Massless_Prop_Momenta(l . ,s32_min,s32_max,ran[l] ) ; 
double s456_max = sqr (sqrt (s32456) -sqrt (s32) ) ; 
vec4d p456; 
double s456; 

s456 = CE.Massless_Prop_Momenta(l . , s456_min, s456_max,ran [2] ) ; 
double amct = 1 . ; 
double alpha = 0.5; 
double ctmax = . ; 
double ctmin = 2 . ; 

double tmass = Flavour (kf :: code(12) ) .mass () ; 

CE . T_Channel_Momenta(pin [0] , pin [1] , p32 , p456 , s32 , s456 , tmass , alpha, 

ctmax , ctmin , amct , , ran [3] , ran [4] ) ; 
double s3 = ms_out [3] ; 
double s2 = ms_out [2] ; 

CE. Isotropic2_Momenta(p32, s3, s2,pout [3] , pout [2] ,ran[5] ,ran[6]); 
double s45_min = Max(pa.ycut_ini()*sqr(rpa.CMS_E()) , 

sqr (sqrt (ms_out [4] ) + sqrt (ms_out [5] ) ) ) ; 
double s6 = ms_out [6] ; 
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double s45_max = sqr(sqrt(s456)-sqrt(s6)) ; 
vec4d. p45; 
double s45; 

s45 = CE.Massless_Prop_Momenta(l . , s45_min, s45_max,ran[7] ) ; 
CE. Isotropic2_Momenta(p456,s45, s6,p45,pout [6] ,raii[8] ,ran[9]); 
double s4 = ms_out [4] ; 

double s5 = ms_out [5] ; 

CE. Isotropic2_Momenta(p45,s4,s5,pout [4] ,pout [5] , ran [10] , ran [11] ) ; 

} 

double P2_5_e_e s_cb_tau_nu_tau_P : : Cl_Weight (vec4d* pin,vec4d* pout, 

double* ms_out) 

{ 

double wt = 1 . ; 

vec4d p32456 = pin[0] + pin[l] ; 
double S32456 = p32456.abs2() ; 

double s32_min = Max(pa. ycut_ini () *sqr (rpa. CMS_E() ) , 

sqr (sqrt (ms_out [3] ) + sqrt (ms_out [2] ) ) ) ; 
double s456_min = Maj!:(pa.ycut_ini()*sqr(rpa.CMS_E()) , 

sqr (sqrt (ms_out [4] ) + sqrt (ms_out [5] ) 

+ sqrt (ms_out [6] ) ) ) ; 
double s32_max = sqr (sqrt (s32456) -sqrt (s456_min) ) ; 
vec4d p32 = pout [3] + pout [2] ; 
double s32 = p32.abs2(); 

wt *= CE .Massless_Prop_Weight (1 . , s32_min, s32_max,s32) ; 
double s456_max = sqr (sqrt (s32456) -sqrt (s32) ) ; 
vec4d p456 = pout [4] + pout [5] + pout [6] ; 
double s456 = p456.abs2(); 

wt *= CE . Massless_Prop_Weight ( 1 . , s456_min , s456_max , s456) ; 
double amct = 1 . ; 
double alpha = 0.5; 
double ctmax = . ; 
double ctmin = 2 . ; 

double tmass = Flavour (kf :: code(12) ) .mass () ; 
wt *= CE.T_Channel_Weight(pin[0] ,pin[l] ,p32,p456, tmass, 

alpha, ctmax, ctmin, amct, 0) ; 

double s3 = ms_out [3] ; 
double s2 = ms_out [2] ; 

wt *= CE. Isotropic2_Weight (pout [3] ,pout [2] ) ; 

double s45_min = Max(pa.ycut_ini()*sqr(rpa.CMS_E()) , 

sqr(sqrt (ms_out [4] ) + sqrt (ms_out [5] ) ) ) ; 
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double s6 = ms_out [6] ; 

double s45_max = sqr(sqrt(s456)-sqrt(s6)) ; 
vec4d p45 = pout [4] + pout [5] ; 
double s45 = p45.abs2(); 

wt *= CE.Massless_Prop_Weight(l. ,s45_inin,s45_max,s45) ; 
wt *= CE. Isotropic2_Weight (p45,pout [6] ) ; 
double s4 = ms_out [4] ; 
double s5 = ms_out [5] ; 

wt *= CE . Isotropic2_Weight (pout [4] ,pout [5] ) ; 

if (!lsZero(wt)) wt = 1 . /wt/pow(2 . *M_PI , 5*3 . -4. ) ; 

return wt; 

} 

int P2_5_e_e s_cb_tau_nu_tau_P: :Cl_Resonances(Flavour*& res_fl) 

{ 

res_fl = new Flavour [3] ; 
res_fl[0] = Flavour (kf :: code (23)) ; 
res_fl[l] = Flavour (kf :: code (23)) ; 
res_f 1 [2] = Flavour (kf : : code (23) ) ; 
return 3; 

} 

Note that only the methods of the class Channel_Elements will be used, for details 
see Sec. 4.5. 

B. A sample for a Mathematica interfaced function 

This is a sample file generated by importing Mathematica output for the calculation 
of a three gluon vertex: 

#include "Mathematica_Interf ace . H" 

using namespace AMEGIC; 

Kabbala Mathematica_Interf ace : :vGGG() 
{ 

return Z(1,0)*(X(2,0)-X(2,1))+Z(2,0)*(X(1,2)-X(1,0)) 
+Z(2,1)*(X(0,1)-X(0,2)); 

} 
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C. The loop over loops technique 



Sometimes it is necessary to have loops within loops to a depth which is not known 
before run time. Then, a technique comes into play which allows an arbitrary number 
of inner loops with different starting and ending values. Therefore three different 
arrays are required, the first one is filled with all beginning values, the second with 
all ending values and the last one is used to store the current combination of loop 
variables. Then a loop is performed until the first variable reaches its endpoint. In 
every step the last variable will be increased (or decreased accordingly). If it gets 
larger than its endpoint, the variable is reset to its beginning value and the variable 
at the previous position is increased (or decreased). Consequently, every time a 
variable reaches its endpoint, the previous one will be increased (or decreased). This 
procedure can be repeated until the first variable is counted behind its endpoint and 
the loop ends. 

D. Test Run Output 

In this section we present a test run output for the given example options in Sec. 5 
and the process e~ e"*" — > uug: 

Starting Timer 
Open File: Te st run/Run . dat 
Open File: Testrun/Particle.dat 
Time: s (clocks=0) 

(User: 0.01 s , System: s , Children User: s .Children System: 0) 
Open File: Testrun/Const . dat 
Open File: Testrun/Const . dat 
No FFS Vertex included in this Model 
No SSV Vertex included in this Model 
No VVS Vertex included in this Model 
No SSS Vertex included in this Model 
Number of Vertices: 21 

1 process(es) ! 

No Value-Library available ! 
Building Topology. . . 
Matching of topologies... 

****File Process/2_3_e-_e+ u_ub_G/Color .dat not found. 

Finding diagrams with same color structure . . . 

2 different color structures left 
++ 
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+ 

File Process/2_3_e-_e+ u_ub_G/Color . dat saved. 

2 Graphs found 

Open File: Testrun/Integration.dat 



using RAMBO for phase space integration 
Starting the calculation. Lean back and enjoy 

Gauge (1): 0.0552225 
Gauge (2): 0.0552225 
Gauge test: 6.28295e-14% 

String test: 0% 

5000. LO-3-Jet: 1906.09 pb +- 2.32851% 



1946.15 pb +- 1.69762% 
1962.73 pb +- 1.39437% 

1986.16 pb +- 1.20933% 
1966.02 pb +- 1.08427% 
1965.21 pb +- 0.988323% 



10000. LO-3-Jet: 
15000. LO-3-Jet: 
20000. LO-3-Jet: 
25000. LO-3-Jet: 
30000. LQ-3-Jet: 
result: 1965.21 
Stoping Timer 

Time: 85.88 s (clocks=8588) 
(User: 71.65 s , System: 0.07 s .Children User: s .Children System: 0) 

Note that this calculation was performed using internal strings for the hehcity am- 
plitudes, if the expressions have been saved into a library, the two last lines would 
look like follows: 

Time: 16.22 s (clocks=1622) 
(User: 16.22 s .System: s .Children User: s .Children System: 0) 

One can see that roughly a factor of 4 can be gained by using the saved libraries. 
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